老项目改造实录：从濒临崩溃到持续交付

接手老项目是每个开发者的必修课。这里的"老"，指的不是代码年龄，而是技术栈停滞、依赖锁定、无人维护的状态。这篇文章记录一次典型的现代化改造，分享可复用的方法论。

第一步：盘家底，别急着动手

改造老项目最大的忌讳是一上来就重构。先做三件事：

1. 摸清依赖树：package-lock.json / requirements.txt / pom.xml 里的版本停留在哪年？哪些依赖已经不再维护？
2. 确认可运行基线：本地能不能跑起来？跑不起来的话，缺哪些配置、哪些环境变量？
3. 梳理数据资产：数据库 schema 谁在维护？有没有历史数据需要兼容？

先让项目在本地稳定运行，是一切改造的前提。 连运行基线都没有的项目，任何重构都是空中楼阁。

第二步：建立自动化护栏

老项目往往没有测试。直接上重构等于裸奔。正确顺序是：

1. 先写冒烟测试（能跑通主流程即可）；
2. 再针对改造涉及的核心模块补测试；
3. 接入 CI（哪怕先只跑 lint + build + 冒烟）。

测试不是为了覆盖率数字，而是为了让你在改完代码后能立刻知道有没有改坏。老项目改造 90% 的风险来自"改了一个地方，炸了另一个地方"。

第三步：渐进式替换，而不是重写

"重写派"通常死得很惨。推荐 Strangler Fig（绞杀榕）模式：像榕树绞杀宿主树一样，在新系统旁边一点点生长，逐步替换老系统的模块，直到老系统自然消亡。

实际执行：

• 优先替换边界清晰的模块（比如独立的微服务、工具库）；
• 每个模块替换后立即上线验证，保持系统始终可用；
• 老接口保留兼容层，通过网关或路由逐步切换流量。

第四步：依赖升级的节奏

依赖升级是重灾区。策略是小步快跑 + 锁定边界：

• 大版本升级（比如 Spring Boot 2 → 3、Node 14 → 20）一次只升一个；
• 每个大版本之间先跑测试再继续；
• 临时性工作绕过：某些依赖真的升级不动，用 patch 或 adapter 隔离，别让它阻塞主线。

经验法则：老项目依赖升级的 80% 痛苦来自 20% 的"钉子户依赖"，学会绕开它们，而不是死磕。

JDK 线的最新坐标：2026 年的新 LTS 是 Java 25（2025 年 9 月发布），非 LTS 的 Java 26（2026 年 3 月）带来了 HTTP/3 支持和更强的反射 API。还在 8/11 的项目，推荐路径是两跳：先 17，再 21/25，每跳之间跑全量回归。

第五步：技术债管理

技术债不是全部要还。分为三类：

• 坏的债（会导致线上事故的）：优先还；
• 可以还的债（影响开发效率但不出事的）：规划还；
• 战略债（当初为了快速上线故意欠的）：保留，可能永远不需要还。

老项目改造的目标不是"变成新项目"，而是让系统重新变得可以持续演进。

踩过的坑

1. 时区问题：老系统存本地时间，新系统用 UTC，混用导致数据错乱。改造第一步就该统一时间规范。
2. 隐式依赖：两个模块通过共享数据库表通信，没有接口边界。这种耦合是改造最大的阻力，需要先划边界。
3. "顺手改一下"陷阱：改造过程中顺手改了个无关逻辑，导致问题定位困难。每次提交只做一件事，老项目尤其如此。

最后

老项目改造的本质不是"写代码"，而是恢复系统的可演进性。盘家底、建护栏、渐进替换、小步升级、管理债务——这套方法论适用于任何规模的老项目。改造完成后你会发现，最大的收获不是技术栈变新了，而是团队重新获得了对系统的掌控感。