前端工程化这个词出现的频率越来越高，一直没有明确的定义，有些人认为是模块化和自动化的工具，比如 Webpack/Gulp、脚手架、组件化等，但工具只是一些辅助手段，并不能作为工程化来理解。
个人认为，前端工程化致力于提升工程的开发效率、协作效率、项目质量，贯穿项目设计、开发、测试、上线、维护的整个过程。
那么，工程化要解决的问题，便是我们在这些过程中遇到的一些问题了。
# 前端项目开发常见问题
相信大家的日常工作中也能感受到，相比于从 0 到 1 搭建项目，我们的大部分工作都是在维护项目，基于现有的项目上进行迭代和开发。正所谓铁打的营盘流水的兵，每个项目都会经历很多开发的参与、协作和交接，在这个过程中常常会遇到很多的问题，这些问题可以分为两类：系统质量的下降，以及开发效率的下降。
# 系统质量
“没有 BUG 的系统是不存在的。” -- 《被删的开发手册》
# 系统质量的下降
BUG 的出现有很多的可能性，比如需求设计不严谨、代码实现的逻辑有漏洞、不在预期之内的异常逻辑分支，等等。除了方案设计和思考的经验不足，BUG 很多时候也会因为对项目的不熟悉、对系统的理解不深入引入，这意味着以下的过程会导致 BUG 的增加：
- 项目频繁地调整（新增或者更换）开发人员，由于不熟悉项目，每个新加入的小伙伴都可能会埋下新的 BUG。
- 系统功能新增和迭代、不断壮大，各个模块间的耦合增加、复杂度增加。如果没法掌握系统的所有细节，很可能牵一发而动全身，产生自己认知以外的 BUG。
对于处于快速迭代、不断拓展阶段的项目来说，不管是人员的变动、还是项目的拓展都是无法避免的。除此之外，为了降低系统的复杂度，当项目发展到一定阶段的时候，会对系统进行局部或是整体的架构调整，比如模块的拆分、各个模块间的依赖解耦、引入新的状态管理工具、重复逻辑进行抽象和封装等等。
新技术的引入会缓解系统复杂度带来的稳定性问题，但同时也可能会引入新的问题，比如：
- 部分功能无法与新技术兼容，成为历史遗留问题
- 较大范围的架构调整影响面很广，可能埋下难以发现的 BUG
可见，一个项目不断发展的过程中，都会面临系统质量下降的问题。
# 提升系统质量
为了提升系统质量，我们需要对项目进行合理的架构调整，提升系统的可读性、可维护性、可测试行、稳定性，从而提升系统发布的稳定性。
我们在进行架构设计时，需要根据项目的预期和现状来设计，保留拓展性的同时，避免过度设计。因此，随着项目不断发展，原有的架构设计可能不再适合，此时我们需要进行优化和调整，比如：
- 引入新的技术和工具
- 团队成员增加，沟通成本和对规范的理解出现差异
- 项目代码量和文件数的增加
- 进行自动化测试能力的覆盖
- 搭建完善的监控和告警体系
在这个过程中，我们可能分别引入了新的代码构建、代码规范和自动化测试工具，搭建了新的监控系统、发布系统、流程控制等，这些都属于前端工程化的一部分。
但是对于开发来说，开发流程变得繁琐，意味着工作内容更复杂，同时还增加了很多新工具和系统的熟悉成本。那么，我们还可以通过优化项目的研发和发布流程，来提升项目的开发效率。
# 开发效率
“今天又要加班了，因为今天的代码还没开始写。” -- 《被删的开发手册》
# 开发效率的下降
系统上线之后，开发的工作内容重心，会从功能开发逐渐转向其它内容。除了新功能的评审和设计以外，还会包括：
- 用户反馈问题跟进和定位
- 线上 BUG 修复和紧急发布
- 处理系统的监控告警，排查异常问题
- 新功能灰度发布过程，自测、产品验证功能、提测、修复 BUG、灰度发布等各个流程都需要人工操作和主动关注
- 为了保证系统质量，需要完善自动化测试能力，包括单元测试、UI 测试、集成测试等
- 项目成员的调整，需要进行工作的交接、指导对方的工作内容等
开发的工作内容变得复杂，需要关注的事情也更多，对于各个系统（监控告警系统、日志系统、测试系统、发布系统等）也都需要熟悉成本和操作成本。在各个工作内容之间切换，也常常容易出现步骤的遗漏，导致一些流程上的问题，比如：
- 系统灰度到一半，处理其它事情忘了全量。
- 系统发布之后，去处理紧急 BUG、忘记看监控，直到收到大量的用户反馈。
- 线上紧急 BUG 修复了，急着发布忘了进行自动化测试。
随着项目规模变大，系统的复杂度也随之上升，上面所提到的工作量也都会增加，开发效率会肉眼可见地受到影响。以前一天工作量的功能开发，如今需要三天时间才能完成，因为每天只有三分之一的时间（甚至更少）可以用来开发新功能。
在这个项目阶段，开发每天的杂事太多、效率太低、浑浑噩噩不知道都做了些什么，团队面临着项目复杂度上升、系统质量不稳定、技术债务越来越多、团队工作效率下降等问题。
# 提升开发效率
项目研发和发布流程优化的核心点在于：将一切需要手动操作和关注的内容自动化。
那么，我们先来梳理下项目开发和发布过程中，到底有多少繁琐的工作可以进行自动化。一般来说，开发在接到产品需求单后，会涉及到分支管理、代码构建、环境部署、测试/验证、问题修复、灰度发布、监控告警、需求单状态扭转等各个流程。
每一次功能发布，都需要花费很多的精力在各个流程步骤上。我们可以将这些步骤都转为自动化，就可以让开发的精力聚焦在功能的设计和实现上。对于流程自动化，业界比较成熟的解决方案是使用持续集成（continuous integration，简称 CI）和持续部署（continuous deployment，简称 CD）：
- 持续集成（CI）：目的是让产品可以快速迭代，同时还能保持高质量
- 持续部署（CD）：目的是代码在任何时刻都是可部署、可进入生产阶段
CI 在项目中的实践，指团队成员频繁（一天多次）地提交代码到主干分支，每次提交后会自动触发自动化验证的任务集合，以便尽可能地提前发现问题；CD 在项目中的实践，指代码通过评审以后，可自动化、可控、多批次地部署到生产环境，CD 的前提是能自动化完成测试、构建、部署等步骤。
CI/CD 在项目中的落地，很多时候会表现为流水线的开发模式：通过建立完整的 CI/CD 流水线，涵盖整个研发流程，可有效地提高效率。一般来说，我们可以搭建这样的 CI/CD 流水线：
- 需求单分配：分配并自动拉取相应 Git 分支
- 代码提交：代码规范检查 + 自动化测试 + 部署测试环境 + 根据需求单配置通知相应的产品和测试
- 产品验证/功能测试：BUG 单自动关联需求单和分支 + 验证完成后，根据需求单通知开发侧
- BUG 修复：代码规范检查 + 自动化测试 + 部署测试环境 + 根据分支 BUG 单和需求单通知测试 + 验证完成后，根据需求单通知开发侧
- 代码合入主干：向团队成员发起代码 Review + Review 通过后代码合入主干
- 日常发布：定时器发起发布流程 + 预发布环境部署 + 进行自动化测试 + 测试通过后进入灰度过程
- 灰度发布：根据配置比例进行灰度 + 灰度过程中自动化进行监控 + 可选择性进入快速回滚流程
- 全量发布：自动扭转需求单状态，并将版本进行归档（Git Tag）
通过将以上流程自动化，可以节省开发的很多人工操作时间、提升开发效率的同时，也避免了人工操作容易出现的遗漏和失误。将自动化流水线与通知/告警机器人、工作群、需求单系统、BUG 系统、代码管理系统、发布系统、监控系统结合，实现全研发和发布流程的自动化，开发可从各种杂事中释放，专注于功能开发的实现。
越是大规模、系统建设完备的团队，开发流程中消耗在多人协作和各个系统的操作中的精力越多，搭建 CI/CD 后更能体会到自动化流程带来的便利。
当然，搭建 CI/CD 的过程中，也需要投入不少的人力精力。因此，很多时候我们可以考虑性价比，从对研发效能影响最大的痛点开始进行建设，可以最快速和有效地提升团队的开发效率，让更多的人愿意参与到 CI/CD 的建设中。
# 结束语
“能用机器解决的问题，就不要依赖人。” -- 《被删的开发手册》
项目维护阶段的最大痛点，其实在于开发无法聚焦自身的工作内容，常常需要在各种系统中进行操作和切换，从而带来开发效率的下降，以及注意力分散、无法更全面的思考导致了不合理的设计、新的 BUG 引入，而影响了系统的质量。
前端工程化的出现，正是为了解决系统质量和效率低下的问题。但前端工程化并不只是局限于代码构建和流水线，可以将其理解为解决项目开发过程中遇到的所有问题，目的在于提升系统质量和开发效率。
