引言

当谈起这个话题的时候，不得不去想到《人月神话》这本著作中所描述的软件工程思想，其中的最后一段总结论述：

软件工程的焦油坑在将来很长一段时间内会继续地使人们举步维艰，无法自拔。软件系统可能是人类创造中最错综复杂的事物，只能期待人们在力所能及的或者刚刚超越力所能及的范围内进行探索和尝试。这个复杂的行业需要：进行持续的发展；学习使用更大的要素来开发；新工具的最佳使用；经论证的管理方法的最佳应用；良好判断的自由发挥；以及能够使我们认识到自己不足和容易犯错的——上帝所赐予的谦卑。

大型前端遇到的问题和困境

在我们的实际项目中，会遇到各种各样的挑战，其中最大的挑战就是：逐渐复杂的领域模型和项目周期快速演进的矛盾。在实际业务推进会很快，随之时间推移，项目中涉及的模块，体系，软件的形态也会变化很快且复杂，随之产生如下问题：

• 最初的架构不在支持当前的变化
• 代码由于多人维护，可读性变差
• 连锁的破窗效应，代码的质量变差。
• 维护成本变大，维护成本不及整体重构。

工程化的解法

当然工程问题，还是需要工程方法来解。我们大体会建立自己的工程体系和规范。通过一系列的工程化的方法论来逐一应对和推进。

建立统一的开发协作环境

这个是工程化的基石：开发工具（IDE 或者编辑器），版本管理体系，构建工具，持续集成平台，项目管理工具。
对于前端项目来说，可以选择的工具还是比较多的。可以列下清单：

工具类型实际工具说明开发工具VSCode，WebStrom，Atom基本上以上三个就是目前大部分前端使用的编辑器，当然也有使用sublime，vim等版本管理工具git ，git-flow，gitlab目前git还是大行其道，但是git的最佳实践还是很多，团队最好还是使用适合自己的版本管理实践构建工具webpack，rollup等自从前端有了node，构建体系也逐步完善持续集成平台jenkins，Travis CI，GitLab CI工程体系不可或缺的一部分，如何保障软件的质量和更新项目管理工具jira，redmine，Trello主要还是进度，沟通，协作工具

这些，目前已经是前端项目开发的标配，在很大程度上可以使用现代化的软件工程技术，提升开发效率和质量，但是在拥有这些基础设施，其实还不够。我们需要在代码开发建立规约和框架，统一编码认知，就是接下来讲的开发框架。

开发框架

我们希望在开发层面上确立和使用统一的编程模式，因此应运而生的就是前端主要三大体系：React，Vue，Angrular。以及对应的三个主要生态体系。当然还有成长中的web component范畴的一些框架：Polymer。当然React，Vue，Angrular也可以实现web component。

此外，如果是大型前端项目，还是需要MVC，MVP，MVVM，或其他的设计模式的概念，当然现在，单向数据流加状态管理也是大行其道。这里就不再赘述了。

引入这些的初衷一定得比较清楚：编写可维护，规范的代码（系统模块的协作，人与人的协作规约）。

模块包管理

大部分工程化的编程语言设计之初都有模块化和包管理的体系，但是JavaScript一开始是没有的，这也是制约前端工程化的主要原因，但是前端开发者在编写一些大型应用时，逐步的建立起模块化和包管理体系。

统一的开发规范

在逐步构建完整前端工程化体系的同时，一个是否重要的部分，代码规范如何落地在整个体系里面呢，可以编写一个规范文档，引入一个代码静态检查工具，还是加上 更加类型严格的TypeScript。当然这些都是已经被证实可行的。
于是在构建过程中，引入了诸多的规范化工具插件。如eslint，stylelint，babel，typescript。

测试，当然还有测试

差点把测试这个给漏掉了，为什么呢，据统计大部分前端代码是没有单元测试的，为什么没有呢，理由很多：需求变化快，需要在修改代码同时，修改单测，测试收益不大；可以直接使用段对端测试，测试人员完成了。这些观念没有问题，当然得想想合理的测试方式，和反思下测试的目的：保证产品质量。可能大部分的情况下会得出一个折中的结论：核心代码，工具，类库需要编写，业务代码可以不用编写单测，通过其他方式（黑盒测试，端对端测试等）进行弥补。最后是要列下测试工具的清单：Mocha，jest，qunit，jesmine，Karma，Chai，ava等等。

工程化总结

控制复杂性是计算机编程的本质。 - Brian Kernighan [Unix的主要贡献者]

前端工程化之路，日趋完善，但是我们拥有了这些，是不是之前提到的问题都可以得以很好的解决呢，事实上答案是否定的。只能说这些工程化工具平台的使用有助于项目的合理推进，有一点积极作用。以此我们引入接下来的思考那我们还缺少什么呢？
我在拥有现代化的前端工程技术的支持下，还是会产生代码维护和开发效能，软件质量等问题。难道就没有一劳永逸的办法吗？如同治疗癌症，就没有特效药吗？是的，目前没有，如同癌细胞，伴随我们一身，不断在突变，同时身体的免疫系统不断的在抵抗，完全是一个动态过程。软件工程也是一样，面最大问题还是变化应对变化的方法，只有持续的控制其发展，才是有效的方法。

如何可持续演进开发

唯一不变的是变化本身。 - Spencer Johnson[《谁动了我的奶酪》的作者]

在软件生命周期中，一切都是动态的，是不断变化的，而我们现有的工程方法论就是应对这些变化而存在的，所以需要在现有工程化的基石上，建立闭环的生命周期，把现有的工具融合在一个生命周期里面。

如何控制变化：工程方法（分治，协同）

软件工程的目标是控制复杂度，而不是增加复杂性。 - Dr. Pamela Zave

作为工程工具在开发中的角色，可以想象成一套水管系统，每一个环节其中的水管的一段或者水管中间的泵。水管中流动的水就是我们需要生出的产品。工程工具系统就是保持软件演进是像活水不断的前进保持活力、
其中主要的思想就是分治和协同，把软件需要完成任务在生命周期中拆分出来，在各个阶段使用工具完成使命，然后采用协同的方式，接入各个时期任务的产物进入下一阶段的产物生成。
通过工具保障产物的质量和效率。但是我们会发现这些工具在软件设计阶段还是相对薄弱的支持，因为关于设计这块更多还是开发者需要去思考的很重要的部分，而通过通用的工程方法显然无法直接覆盖和解决。为了提升开发统一和效率开发框架应运而生和同时产生DSL的编程方式，在大方向上指导，如申明式编程，响应式编程，面向对象编程等编程范式和对应的最佳实践框架。
如何组织模块，架构，代码都必须是开发人员自己该去思考部分。而这部分思考最终会导致程序产出内容好坏和可维护性。所以引出了如下话题：如何设计变化：架构。

如何设计变化 ：架构(拆分，组合)

取势 明道 优术 -长江商学院校训（最早出自《道德经》，《孙子兵法》）

这里用"取势 明道 优术"来开篇，主要这三个层面的方法论可以指导我们做出正确的设计和架构，取势：顺势而为，找到软件产品的本源，本身用来做什么的，他的方向是什么，这个层面是最重要的。接下来明白了方向和产品的本源，那我们就要思考如何使用正确的方法，原则来设计软件架构，这个就是所谓的明道。接下来就到了第三个层面，优术，可以用商业本质的4个字来诠释优术：多快好省，归纳到我们软件工程方面就是质量和效率提升的方法和工具。
所以，做什么，为什么要这么做，怎么样做？只有把这三层问题回答了，对于架构的产生和理解就顺其自然了。设计主要是在完成这本源问题的解决。如果要确定三个层面“取势 明道 优术”，架构设计就是实现取势，明道这两个的问题解决。
前人在设计架构方面提供了很多经验和典范，方法，原则，有领域驱动设计，设计模式，测试驱动开发，行为驱动开发，面向对象编程，面前切面编程，响应式编程，申明式编程，DRY原则，开闭原则（OCP），CAP原则，12factor...
有很多，不一一列举，而且要掌握这些需要靠实践积累和学习，要做到活学活用，必须在具体实践中使用，理解，验证，使其符合发展规律。

如何治理变化: 开发资产(粒度，标准)

无为而治 -老子《道德经》

以无为而治开题，并不是说不去做什么，而是顺应变化和自然去治理的意思，如果只是这样那就不是无为而治，变成了无治了。无为的意思是不对具体细节加以干涉，过多的管理和操作的意思，另一方面，不去关注细节，也就是可在方向和变化本身的趋势更多的关注，认识整个发展过程，建立起开发资产的生态。关键点：形成开发资产的自治和进化。

所以，这里需要我们在更高的层面去思考治理变化这件事情，如何建立一个自治的开发生态体系？
主要可以分成以下几块：

• 资产系统化：资产共享共建平台。
• 资产标准化：确定开发资产的特性和类型，及其规范（工具，组件，插件，服务）。
• 业务领域化：建立业务知识图谱和领域划分，系统架构图。
• 培训体系化：可以共享共建的WorkShop（知识和能力学习系统）。
• 共建激励机制：明确开发资产价值，贡献值。作为团队加分项。

这几个模块是互相依存的，大体关系如下：

每一块的构建都有很多需要去思考和完成的，这里只是提纲挈领的列出来，后续可以有单独的篇幅的阐述每一个部分的内容。这里我们主要关注各个模块之间的关系，如图所示，最底层是需要建立一套激励机制，保障上层各个模块建设和执行的动力。通过明确事务和资产的价值，产生正向的激励，推动执行。接下来培训体系，用于团队自我进化的一套体系，主要起到知识连接传承的作用，帮助团队认知统一，然后可以通过，workshop，进阶课程，竞赛，资质认证，专业评定等方式来落实。标准规范，是开发工程化和资产化的基础，需要确定流程，编码，质量，部件标准等。最终我们真正得益的开发资产和知识图谱，有了明晰的资产和图谱，在产品应用构建的时候，可以极大提升效率和质量，同时也有了全局的视角来指导产品方向。

进一步：从自动化到智能化

在软件开发过程中，一直在致力于构建高效的，准确的解决实际问题的方案，技术的革新也是在整个人类可以发展的大趋势下不断演进和突变，我们纵观历史，从电气化时代到信息化时代，主要的技术革新是计算机和网络快速发展，那我们的下一个革新可能是机器的智能化，从运算智能，感知智能和认知智能的突破，而对于我们所处的计算机行业影响比较大，对于软开发来讲，原来是人所需要做的事件可以由机器来完成，从最初单一逻辑事项，逐步进化到感知逻辑的事项，最后到认知逻辑的事项，逐步由机器替代。变成了人类自治到机器自治。逐步软件构建，治理从自动化到智能化晋级。

结语

只有不断孜孜不倦的思考问题和问题本质，才能逐步从大型项目的困境中突围。同时，问题也在随着方法论进步而变化出新的问题，所以还是已《人月神话》的结尾，保持谦卑，砥砺前行。