前端工程化分为哪几个阶段？

项目需要走多远，分清优先级，不要拿着锤子找钉子。

前言

在开展项目的工程化/基建的工作之前，需要怎么做？

第一步需要先熟悉项目当前的现状，是效率不够高？哪个环节效率不够高？是质量不好？测试环节还是交付环节？先盘下问题、然后归类。

第二步是扩大视野，知道了当前现状，就要去想在某个场景下当前的解决方案好不好，有没有更好的方案替代，成本如何，这一步很重要，需要想明白可以做到多深以及项目需要做到多深。

每个阶段的工程化，都可以大致分为提效和质量两方面，细分可以是工具化、组件化、自动化以及流程上的完善程度。

阶段一

工具层面

1. 独立环境 独立环境有个很大的好处就是不会相互影响，不会写着业务代码突然环境崩了。现在的项目基本上是前后端分离的，天然可以运行在自己电脑上，但如果真的需要后台环境或者数据库环境，尽量避免都 ssh 到一台本地机去跑，可以弄个 Docker 镜像在自己电脑上跑。

2.构建器/打包工具 能够支撑项目所需功能，比如 ts、tsx、css in js、babel、mock 等。市面上的 cli，比如 cra、vue-cli、vite 足以满足。

3.编译/构建速度快 项目大，改动一行代码，编译10分钟（如果你也写 Java 的话）。可以看出这个速度不能够支持快速开发和调试，阻断心流状态。前端部分大多都是冷启动和打包的时间慢，开发和调试都是增量更新的。常见的做法是提高机器性能、拆包拆项目、缓存、用更高性能的工具。

自动化

1.CI 构建一条项目开发的流水线，比如 git 分支模型、pre-commit 的 lint 流程、push 之后的自动化构建流程、构建完成后的自动化检测流程（规范、测试、性能都可以），能交给机器的不要投入太多人的时间。

2.CD CI 是研发过程流水线，那 CD 是部署过程流水线，一般需要打通运维的部署平台、AB 测平台等等。比如运行 publish 命令就能把前端资源部署到静态资源存储、Node 环境部署等，让开发免运维。

模块化、组件化

1.基础模块接口完善、补全文档 模块化是多人协同编码的基础，将整体的复杂度拆分到每个人能处理的程度。在设计阶段，需要有一个熟悉整体业务和编码质量高的人去拆分各个模块，定义模块的规范、协议、接口等，接口一定要表达清晰（尽管内部写得很挫）。

2.基础组件库、业务组件库重用 我们要做乘法的事情，也就是做一遍，多个功能都能受益。组件库是一个例子，它可以在多项目复用、甚至多端复用。一般也不会自研，都是拿市面上的组件库进行拓展，比如定制一套符合公司设计规范的主题系统、开发新的业务功能等。

流程完善

1.需求评审 是否经常收到一句话需求？需求有明显的坑都没发现？增加需求评审流程，定义每个需求的规模、优先级，排除明面上的不合理的点，避免一句话的需求。需求排期需要研发预研实现、按 WBS 拆分，给出一个相对的时长（一般都需要加上 buffer 系数）。

阶段二

自动化

1.编写 E2E 测试用例和全量回归 因为 E2E 测试用例是非常多的，很耗时间，如果每次构建后 CI 自动跑花费的时间和机器很不划算（尽管是并行的），可以每天晚上定时跑全量回归，第二天早上去验收。

平台化

1.监控平台 服务监控是稳定性治理很重要的一部分，在前端部分里，有脚本错误监控、资源错误监控、Node 服务监控等，中大型公司有自研的一套系统，开源的有 Sentry、X-Profiler 等。监控的目的是尽早发现线上问题，从而快速修复，降低用户感知错误，流程上需要制定线上“救火”标准，比如1分钟发现、5分钟定位、10分钟恢复。

2.性能BI平台 性能的好坏是体验度量很关键的一部分，业界有 LCP 、秒开率等的标准，开源的数据平台比如 MetaBase、Grafana 也已经很成熟，可以继承一套集性能规范、数据上报、数据清洗、报表的平台。进一步可以把业务指标、NPS 拉通一起看，总结提高性能能够得到多少业务价值。

3. 页面搭建平台 官网页、活动页、游戏化页面是重运营，是拉新的一个重要手段，这些需求普遍量大且没有什么技术含量，光靠堆人是不够的，可以使用页面搭建平台，抽象基础模块、素材等，降低研发成本。因为搭建平台是跟业务强绑定的，所以开源的并不多，可以参考阿里的 lowcode-engine、腾讯的 tmagic。

框架完善

不需要关注构建、部署等流程了，但编码实实在在仍需要关注目录划分、页面路由、SSR、接口请求等，如果没有一个现成的框架提供支持以及约束，很快就会变成各写各的，没有规范，容易埋坑，效率不高的情况。在开源的框架里面，Next.js 是备受关注的，国内的有 Umi.js、Ice.js ，从中可以吸取他们的设计原则，比如 Falling Into the pit of success 。

流程完善

为了编码规范和质量，我们不得不采取一些强制的手段，比如 CodeReview，是基于 feature 分支模型的集成即 review，还是集中式的开会 review ，我并没有太强烈的推荐意愿，因为没太多实践经验。

CaseStudy，技术上犯错不可避免，但可以沉淀经验，形成规范，避免再次犯错。CaseStudy 很重要一点是要找出根问题，没找到本质问题去解决仍然有再犯错的可能。另外，对犯错有惩罚制度，对优化也应该有奖励制度，否则就会人人都害怕做错，人人都不去做的局面。

CheckList，比如上线流程需要检查的列表、研发提测需要检查的列表，这些都是前辈们一步一步坑踩过来的，一个一个 CaseStudy 过来的，对此除了要严格遵守外，也要检查里面的规则的时效性，这个规则几年前适用，如今某个工具出来了，是否交给工具自动化？

前沿

AI的能力加持下，我们能否辅助编程？答案是肯定的，比如 Github Copilot、阿里的 ImgCook，自动生成测试用例、UI2Code 等，尽管现在不太成熟，但这个是大趋势，尽早学会尽早享受。

WebIDE，既然每个开发都需要经历搭建环境、依赖安装、打通构建和发布，为何不直接打开个浏览器即可编码？毕竟浏览器是每个电脑上都安装了，点开即用，用完即走。

总结

这一小节说明了前端工程化能做到什么程度，当然这只是我的一家之言、所见所闻，各位看官可以辩证地看待。

知道了能去多远，然后需要知道当前项目需要走多远，分清优先级。不要拿着锤子找钉子，毕竟大厂的基建是有一个团队在维护，反观你的项目里可能人手很少，边开发业务边做基建，在大厂里是重要紧急的事情，可能到你这是不重要也不紧急，所以，适合很重要。