第3章 架构基础：工作流设计

前端基础架构是一系列工具与流程的集合，它是我们在启动一个项目时所需要制定的一系列规范和规划。每当我们启动一个新的项目，所要做的事情会很多。

在ThoughtWorks，我们称这个时间段为Iteration 0，即I0或者迭代0。不同的时期，我们对于项目启动会有不同的看法。以笔者为例：

1.0时期，迭代0就是选定一个前端框架。刚工作时，这段时间所要做的事情，就是从众多前端框架中选一个。选定框架本身就是一件麻烦的事，要进行一堆细致的分析才能决定使用哪一个。如果组织内没有规定好框架，那么选择框架便相当复杂。当笔者真正去启动一个前端项目的时候，发现迭代0并不是选一个框架、写一个“Hello, world”那么简单，还需要搭建一个持续集成环境。在搭建持续集成环境的过程中，仍需要编写前端应用所需要的构建脚本。于是，迭代0所做的事情就变得更复杂。

2.0时期，迭代0应该是选定前端框架+完整的构建脚本和构建系统。在笔者随后经历的项目中，这个模式很好。原因是在这些项目里，笔者只是负责一个小团队的架构。当需要负责一个更大的项目、更大的团队时，需要从组织的层面去考虑这个问题。对于一个大的前端项目，其前端架构要让所有的团队都可以一起构建这个应用，但相应的代码不能在同一个代码库里。此外，还有一个麻烦的问题就是规范化。在小的团队里，规范可以口头约定，而在大的团队里，规范一定是可以自动化的。

3.0时期，迭代0应该是选定前端框架+完整的构建脚本和构建系统+流程规范化。在笔者接触一些更大规模的团队时，发现在团队里要做的事情就更多了。从组织本身的安全和能力提升出发，我们应该开发自己的前端开发框架。从用户体验和开发人员的便利性上看，我们应该做出自己的前端Design System。为了降低开发成本，我们还需要拥有一些前端应用脚手架、自己的开发工具或者协作工具。于是，工作的重心便从业务转向了构建工具。

这样仔细一看发现：哦，这是和团队规模密切相关的啊。为了保障团队能顺利合作开发，我们需要制定一系列的开发流程，并创建相应的开发规范。

技术在不断演进，帮助我们不断地提高生产力、使流程规范化。过去我们手动下载依赖，现在可以一键安装依赖；过去需要单独进行测试，现在可以在提交代码后自动测试。随着我们不断地优化开发流程，这些工作越来越自动化。

原先，我们只是出台一系列规范，期盼团队中的成员能遵循，然而规范在这个时候只是规范而已。现在规范被硬编码到流程中，一系列的操作都由程序来进行检测——使用Lint工具对代码风格进行检验，使用测试覆盖率检测测试是否测试过等。这些流程旨在通过规范代码来提升代码的可阅读性，减少代码中可能出现的bug。

当然，硬规范有好的方面也有不好的方面。好的方面是，它可以产出更规范的代码；不好的方面是，它让我们千篇一律。至于使用哪种方式，具体还要看情况——从两个方案中选择时，我们往往是从两个不好的中选出一个较好的。

这些流程与规范，就是我们要在本章中讨论的内容。