语言选型

出于公司发展、市场环境变化、产品迭代需要等原因，我们要做好语言的选择，而语言本身没有优劣好坏之分，选择哪种语言，完全看我们的环境是什么。通常选择语言要从以下几个点去考虑：

团队

语言选择首先要考虑能不能找到这样的团队，也就是说要在合适的时间选择一个合适的团队，团队对某种语言的驾驭能力，将是你开始及发展壮大的一个很重要的因素。

成本

我们做项目的时候，时间、成本、质量是考量的三个维度。用到架构里，我们就要考虑所选择的语言是不是在成本承受范围里。另外，这个成本的考量要综合，要考虑到人员培养的周期、学习的周期、团队配合的周期，以及人员流失带来的人力成本。

控制

对选择语言的控制力，包括团队领导对这种语言是否有理解和控制力，对其他成员学习这种语言的成本控制的力度，这些也都影响语言的选择。

项目特点

根据不同的项目需求，最终选择最适合这个项目的语言。在初期尽量保证语言的统一性，因为人员可调配，建议初期不用过多考虑语言在处理某方面的优势。

技术健壮性

技术健壮性包括文档安全、技术安全、文档的健全程度、活跃度、成熟度、是不是能一直持续更新等。这些也都是我们选择某一种语言技术的关键因素。所以要选择某个语言，我们通常要考虑到今后是否持续更新，否则就和现在很多开源项目一样逐渐销声匿迹。未来你再遇见问题的时候，可能只有自己去维护，可自己能维护这个开源框架的话，错认为还不如自己写一套。

技术多样性

语言的选择的时候一定要考虑多样性首先，语言多样性有利于团队持续发展和稳定，团队持续发展稳定了，公司才能持续发展和稳定；其次，语言多样性能带来更多的选择，利于实现产品合作；最后，语言多样性也是人才培养的一种方式，对整个行业有利。

当然，这不是一成不变的，如果有可能的话，我们应该保证语言的统一，这样的话在初期的时候，我们的人员是可以标配的，当有小项目的时候，分出小组，可灵活组合。关键还是可控的。CTO要有这个意识：通过团队去控制语言，而不是通过语言去控制团队。

学习成本

出于人员培养的周期、学习的周期、团队配合的周期、人才流失的周期等成本考虑，我觉得在团队的日常建设中最好能做到平稳过渡，人员建设有梯度低层输送学习进取型人才中层输送高输出进阶型人才高层输送管理业务骨干型人才这样每个人发挥强项，互相依赖、互相配合，而且可以逐级引导。

在培养团队的时候，CTO要注意高端输出型人才培养，这决定了团队在关键项目是否给力。对于 150 人到 200 人的团队，理想状态是中高端有大批的后备军，而且有几个人能够带领团队前行（一到两个人就足够了），这个团队就很稳。

容器选型

我个人认为，容器的选择其实比语言的选择要容易一些，主要是当你选择一个很好的容器，性能就会有一种很大的提升。这种选择的背后其实就是成本、时间、质量这三个纬度的PK.

例如，公司发展到一定规范的时候，质量要求越来越高，然后对于时间的要求也越来越高，时间固定，质量固定，唯一能做的是增加成本。你想想怎么加成本能搞定这个事，可以加班、加人手、也可以增加硬件成本。

未来某一天我们能否做到这一点：投了很少的时间和成本、质量却挺高，这其实就是技术创新了，这时候我们就能解决发展的痛点。通过创新方式去创造奇迹，比马跑得快的一定不是马车，所以要换角度去重新思考痛点。

笔者认为长远地看，好的架构是改出来，短期地看，架构是设计出来的。中长期来看架构是边设计边改出来的。

架构更多的是解决我们现有的痛点，就跟创业一样，我觉得做架构就是在做技术创业，架构设计的非常好，我们真正的能用多少东西呢？用的东西并不是特别多，所以往往设计出来的东西属于过度设计，从而导致过度开发，所以架构上，设计的成分固然重要，但长远看，其实架构是改出来的。

企业的发展是从无到有、从小到大的过程，而企业产品演化的方向同样也是变化的，而且有时间和成本的限制，因此架构在前期、中期、后期需要考虑的点都不一样，前期要的是快和节约成本，尽快面市；中期用户数长上来了，就要考虑安全性、扩展性、稳定性了。所以一个合格的架构师，在我看来，应当因地制宜地选择语言，选择合适的容器和合适的架构，如果能够把团队里的人员、技术、规划、时间、成本、效率，还有幸福度等资源统一协调好，以实现工作目标，我觉得这才是一个合格的架构师。这也是我为什么固执地认为架构是一种文化，而不是单纯的技术。

庞大的系统进行解耦

解耦主要用的逆向思维，这一点和写游戏外挂非常相似。那么，庞大的系统是如何进行解耦的，解耦是否有规律可循，我个人的理解是要具体情况具体分析，但肯定是有规律可循的。

第一步，“抽象＋分层”是对解决方案（代理模式）的整体把握，按照业务拆。举例，有一个老系统，它的软件不开源，是什么我不知道，好在这个数据库我能看得见，为了实现扩展，我们做新系统要实现二者的交互，就要加一个抽象的代理层，相当于在这个系统之外再做一个系统，相当于外挂。

第二步，在模块内，熟悉系统，研究数据流。用逆向工程模拟交互接口，一步步拆分。就像我们做一个项目，应该是把一个项目需求全部细分成可持续的共同点，对于这个共同点进行技术评估，评估完以后进行排期。同样的原理，我们对原有的一个系统进行分析，分析完以后，你能逆向出数据表结构最好，好在成型的系统如果文档不全，命名至少是拼音加英文。

第三步，按照功能和数据流向逐一替代，前期设计与数据同步，数据问题需要写外挂去处理。思路和游戏外挂一样的，就是要用大量的逆向工程把系统全部拆出来。

第四步，对数据进行收集，用数学归纳法，要注意的是切分过程一定会有脏数据。针对脏数据，收集bug.数学归纳法穷举问题，分析在每一个流向的时候呈现什么问题，然后有什么样的问题导致这样的情况，然后对它进行修复。

第五步，最后打破现在方案，根据对现有业务的需求，重新设计（按照业务需要设计，并非技术架构）。

接下来，我们用电商业务流程和架构举例。

主流电商业务流程

在主流电商平台中，若需精细化管理各个业务流程，一般会涉及上百个子系统，系统之间的交互接口更是不计其数。任何系统环节出现问题，都会对业务带来或多或少的影响。

这里几个大的模块，有基础数据的建档，包括采购入库、退货供应商、电商退换货、电商出库这些东西都是以前软件里的，把它拆分出来，拆出来以后再进行统一布局和升级。发现有的部分拆出来了，还有一部分系统还没有拆出来，但我们都绘制出来，就是说，如果要想对一个系统拆分的话，必须得把这个系统所有的业务模型全部都绘制出来，数据流向全部要摸清楚，你才可以一步一步地去替换。

企业的系统流程

从上图中可以看出，在实际的应用中，会规划出所有的模块，包括具体的功能，最后就和玩卡牌游戏一样，一个一个的重构，替换，或者重新开发。最终把整个系统编织出来。

设计的理念

假定给我一个命题，在半个小时内教会一些实习生采用 JavaScript 语言进行目前的一些项目的开发，他们的能力只限于一些常规的基础知识，没有真正做过项目。

如果按照常规的方式，我只能说我没有办法，因为受限他们的理解，还有我对质量的要求，还有就是他们很多人根本没办法上手，如果一点点教，时间半个小时肯定不够。但是命题就是如此，我应该怎么才能做到呢？这里除了用创新的方式，别无它法。

这里我想引出一种技术框架，这种叫约定式开发。我们怎么能够让不太会写 JavaScript 的人，会写 JavaScript，并且写的好呢？

这时我们要有个理念，配置优于编码，也就是让一个不太会写代码的人，通过这种配置的方式可以让引擎自动去生成代码。

试想编写完整规范的模块，并且书写风格优良简单，问题是我们如何把它传给别人，并且保持一致？如果我编写一个公用模块给大家用，编写规则引擎，别人只需要按照规则引擎的要求去写一些简单的配置，具体的实现代码是引擎自动生成的。这个时候，我们可以认为代码是自己生成的，我们只负责配置。

但是问题来了，配置文件越来越多，要让不太会写的人也能写出来，虽然降低了编码学习成本，但是至少还要学习写配置文件。这里笔者认为，少写代码可以减少复杂度，约定式开发就是一种很好的方式，配置优于编码，但是比配置更极致的方式是约定。这样我们就可以大量减少配置文件。

懂点原理，会用鼠标，我认为就可以去编程，这是我认为的一种设计理念，也是一种架构思维，这种架构思维叫约定式开发，现在有很多前端技术，里面都有这样的一种设计思想。也许未来我们的生活，编程是人们的标配，就像司机这个职业，现在人人基本上都可以开车。也许未来我们能够通过说话，就在下达计算机指令，会有代理机器人对我们的指令进行分析，通过我们的话语进行编码。