我过去讨厌标准化，那种讨厌是发自骨子里的。

我曾坚定地认为，每个项目都该有自己的独特风味。不同的构建工具？当然可以。不同的文件夹结构？为什么不呢。不同的部署脚本？这样才能让事情变得有意思，对吧。

我错得很彻底。

上个季度，我接手了5套用PHP写的前端旧系统。它们来自不同团队，诞生于不同年份，浸润着不同浓度的咖啡因式狂想。虽然这5套系统服务于完全相同的业务目标，但实际维护起来，简直像在处理5种不同语言写出来的东西。

先看看我接手时的真实情况：App A 跑在 PHP 5.6 上，没有任何构建工具，通过 FTP 手动拖拽文件部署，接手开发者的精神损耗很高。App B 升到了 PHP 7.0，用了 Gulp 做构建，通过 SSH 配合一套自定义 bash 脚本发布，接手开发者的精神损耗非常高。App C 是 PHP 7.4，引入了 Composer 做依赖管理，接了一条早就坏掉的 Jenkins 流水线，接手开发者的精神损耗极高。App D 总算用上了 PHP 8.0，Webpack 用得半生不熟，Kubernetes 部署也只是勉强搭起来，精神损耗中等。而 App E 又回到了 PHP 5.6，构建工具是个无法描述的噩梦，部署全靠祈祷，接手的精神损耗直接拉满。

这就带来了一个极度荒谬的现实：想让一个新加入的开发人员动手写一行生产代码，必须先花整整一周时间去解释每个应用的诡异之处。一周时间，全部消耗在对历史遗留问题的口耳相传中，没有一行代码产出。

于是我提了一个听起来非常激进的方案：把它们全部干掉。

准确地说，不是干掉，是迁移。把所有这5套前端全部整合进我们现有的标准 Node.js 流水线里。一套构建流程，一种部署策略，一种做事情的方式。反对的声音立刻就涌上来了：“PHP明明好好的！”“为什么要修没坏的东西？”“这至少得花好几个月！”“我们会丢掉自己的特色！”

我只回了一句：“你们的特色正在让公司白白烧钱。”

迁移的实际过程没有想象中那么可怕。第一步是对5套应用进行一次彻底盘点，我把每一个特性、每一条路由、每一次 API 调用全部绘制成图。结果发现了一件非常有意思的事：它们实际上都在做完全相同的三件事——从 API 拉取数据、渲染用户界面、处理表单提交。真正的差异仅仅在于实现方式上的东拼西凑。

接着我定下了标准化的 Node 管线：框架就用团队已经在别处使用的 Express 加 React；构建交给 Vite，够快也够现代；代码规范检查用 ESLint 加 Prettier，这一点没有任何商量余地；测试用 Jest 加 React Testing Library；部署则通过 GitHub Actions 直接推到 AWS ECS。

实际的代码改写并没有从头造轮子。我把共享的 UI 组件抽进一个 monorepo 包里，把 API 客户端逻辑合并成单独的服务，再把所有环境配置整合进一套统一的 dotenv 环境变量体系中。每套旧应用在新的代码库里，只是以不同“主题”或“路由”的形式重新实现一遍。最后一步是分批切流量。我们一次只上线一个应用，一旦出现问题就立即回滚。整个过程里确实翻过两次车，我们也确实原样回滚了两次，没什么大不了的。

最终的结果让我觉得这比任何炫技都有价值得多。

新成员入职上手时间从整整一周被压到了短短一天。这是整件事里我最引以为傲的一个数字。大家可以对比一下迁移前后的场景。以前：第一天，试着在 M1 芯片的 Mac 上装 PHP 5.6，祝你好运；第二天，配置5套不同的 php.ini 文件；第三天，学懂 App A 那套自定义路由机制；第四天，再学 App B 那套自定义的模板引擎；第五天，也许能真正开始写一点代码。现在：上午，执行 git clone、npm install，再复制一份环境变量示例文件；到了下午，就可以直接和新同事说：“代码库全在这儿了，你懂 React，也懂 Node，直接上手干吧。”