用进化的思维做架构文档格式.docx

1、我们做项目的时候，时间、成本、质量是考量的三个维度。用到架构里，我们就要考虑所选择的语言是不是在成本承受范围里。另外，这个成本的考量要综合，要考虑到人员培养的周期、学习的周期、团队配合的周期，以及人员流失带来的人力成本。控制对选择语言的控制力，包括团队领导对这种语言是否有理解和控制力，对其他成员学习这种语言的成本控制的力度，这些也都影响语言的选择。项目特点根据不同的项目需求，最终选择最适合这个项目的语言。在初期尽量保证语言的统一性，因为人员可调配，建议初期不用过多考虑语言在处理某方面的优势。技术健壮性技术健壮性包括文档安全、技术安全、文档的健全程度、活跃度、成熟度、是不是能一直持续更新等。这些

2、也都是我们选择某一种语言技术的关键因素。所以要选择某个语言，我们通常要考虑到今后是否持续更新，否则就和现在很多开源项目一样逐渐销声匿迹。未来你再遇见问题的时候，可能只有自己去维护，可自己能维护这个开源框架的话，错认为还不如自己写一套。技术多样性语言的选择的时候一定要考虑多样性 首先，语言多样性有利于团队持续发展和稳定，团队持续发展稳定了，公司才能持续发展和稳定； 其次，语言多样性能带来更多的选择，利于实现产品合作； 最后，语言多样性也是人才培养的一种方式，对整个行业有利。当然，这不是一成不变的，如果有可能的话，我们应该保证语言的统一，这样的话在初期的时候，我们的人员是可以标配的，当有小项目的时

3、候，分出小组，可灵活组合。关键还是可控的。CTO要有这个意识：通过团队去控制语言，而不是通过语言去控制团队。学习成本出于人员培养的周期、学习的周期、团队配合的周期、人才流失的周期等成本考虑，我觉得在团队的日常建设中最好能做到平稳过渡，人员建设有梯度 低层输送学习进取型人才 中层输送高输出进阶型人才 高层输送管理业务骨干型人才这样每个人发挥强项，互相依赖、互相配合，而且可以逐级引导。在培养团队的时候，CTO要注意高端输出型人才培养，这决定了团队在关键项目是否给力。对于 150 人到 200 人的团队，理想状态是中高端有大批的后备军，而且有几个人能够带领团队前行（一到两个人就足够了），这个团队就很

4、稳。容器选型我个人认为，容器的选择其实比语言的选择要容易一些，主要是当你选择一个很好的容器，性能就会有一种很大的提升。这种选择的背后其实就是成本、时间、质量这三个纬度的PK。例如，公司发展到一定规范的时候，质量要求越来越高，然后对于时间的要求也越来越高，时间固定，质量固定，唯一能做的是增加成本。你想想怎么加成本能搞定这个事，可以加班、加人手、也可以增加硬件成本。未来某一天我们能否做到这一点：投了很少的时间和成本、质量却挺高，这其实就是技术创新了，这时候我们就能解决发展的痛点。通过创新方式去创造奇迹，比马跑得快的一定不是马车，所以要换角度去重新思考痛点。笔者认为长远地看，好的架构是改出来，短期地

5、看，架构是设计出来的。中长期来看架构是边设计边改出来的。架构更多的是解决我们现有的痛点，就跟创业一样，我觉得做架构就是在做技术创业，架构设计的非常好，我们真正的能用多少东西呢？用的东西并不是特别多，所以往往设计出来的东西属于过度设计，从而导致过度开发，所以架构上，设计的成分固然重要，但长远看，其实架构是改出来的。企业的发展是从无到有、从小到大的过程，而企业产品演化的方向同样也是变化的，而且有时间和成本的限制，因此架构在前期、中期、后期需要考虑的点都不一样，前期要的是快和节约成本，尽快面市；中期用户数长上来了，就要考虑安全性、扩展性、稳定性了。所以一个合格的架构师，在我看来，应当因地制宜地选择语

6、言，选择合适的容器和合适的架构，如果能够把团队里的人员、技术、规划、时间、成本、效率，还有幸福度等资源统一协调好，以实现工作目标，我觉得这才是一个合格的架构师。这也是我为什么固执地认为架构是一种文化，而不是单纯的技术。庞大的系统进行解耦解耦主要用的逆向思维，这一点和写游戏外挂非常相似。那么，庞大的系统是如何进行解耦的，解耦是否有规律可循，我个人的理解是要具体情况具体分析，但肯定是有规律可循的。 第一步，“抽象分层”是对解决方案（代理模式）的整体把握，按照业务拆。举例，有一个老系统，它的软件不开源，是什么我不知道，好在这个数据库我能看得见，为了实现扩展，我们做新系统要实现二者的交互，就要加一个抽

7、象的代理层，相当于在这个系统之外再做一个系统，相当于外挂。 第二步，在模块内，熟悉系统，研究数据流。用逆向工程模拟交互接口，一步步拆分。就像我们做一个项目，应该是把一个项目需求全部细分成可持续的共同点，对于这个共同点进行技术评估，评估完以后进行排期。同样的原理，我们对原有的一个系统进行分析，分析完以后，你能逆向出数据表结构最好，好在成型的系统如果文档不全，命名至少是拼音加英文。 第三步，按照功能和数据流向逐一替代，前期设计与数据同步，数据问题需要写外挂去处理。思路和游戏外挂一样的，就是要用大量的逆向工程把系统全部拆出来。 第四步，对数据进行收集，用数学归纳法，要注意的是切分过程一定会有脏数据。

8、针对脏数据，收集bug。数学归纳法穷举问题，分析在每一个流向的时候呈现什么问题，然后有什么样的问题导致这样的情况，然后对它进行修复。 第五步，最后打破现在方案，根据对现有业务的需求，重新设计（按照业务需要设计，并非技术架构）。接下来，我们用电商业务流程和架构举例。主流电商业务流程在主流电商平台中，若需精细化管理各个业务流程，一般会涉及上百个子系统，系统之间的交互接口更是不计其数。任何系统环节出现问题，都会对业务带来或多或少的影响。这里几个大的模块，有基础数据的建档，包括采购入库、退货供应商、电商退换货、电商出库这些东西都是以前软件里的，把它拆分出来，拆出来以后再进行统一布局和升级。发现有的部分

9、拆出来了，还有一部分系统还没有拆出来，但我们都绘制出来，就是说，如果要想对一个系统拆分的话，必须得把这个系统所有的业务模型全部都绘制出来，数据流向全部要摸清楚，你才可以一步一步地去替换。企业的系统流程从上图中可以看出，在实际的应用中，会规划出所有的模块，包括具体的功能，最后就和玩卡牌游戏一样，一个一个的重构，替换，或者重新开发。最终把整个系统编织出来。设计的理念假定给我一个命题，在半个小时内教会一些实习生采用 JavaScript 语言进行目前的一些项目的开发，他们的能力只限于一些常规的基础知识，没有真正做过项目。如果按照常规的方式，我只能说我没有办法，因为受限他们的理解，还有我对质量的要求，

10、还有就是他们很多人根本没办法上手，如果一点点教，时间半个小时肯定不够。但是命题就是如此，我应该怎么才能做到呢？这里除了用创新的方式，别无它法。这里我想引出一种技术框架，这种叫约定式开发。我们怎么能够让不太会写 JavaScript 的人，会写 JavaScript，并且写的好呢？这时我们要有个理念，配置优于编码，也就是让一个不太会写代码的人，通过这种配置的方式可以让引擎自动去生成代码。试想编写完整规范的模块，并且书写风格优良简单，问题是我们如何把它传给别人，并且保持一致？如果我编写一个公用模块给大家用，编写规则引擎，别人只需要按照规则引擎的要求去写一些简单的配置，具体的实现代码是引擎自动生成的。这个时候，我们可以认为代码是自己生成的，我们只负责配置。但是问题来了，配置文件越来越多，要让不太会写的人也能写出来，虽然降低了编码学习成本，但是至少还要学习写配置文件。这里笔者认为，少写代码可以减少复杂度，约定式开发就是一种很好的方式，配置优于编码，但是比配置更极致的方式是约定。这样我们就可以大量减少配置文件。