技术债务：从“救火”到“重建”，我是如何把老项目救活的

引言：一个被遗忘的角落

去年年底，我接手了一个“看起来还能用”的老系统。它是一个在线教育平台的核心模块之一，负责课程发布、报名与支付流程，已经上线快五年了。这个系统原本是公司最早的产品之一，经历过多次迭代和功能堆砌，代码库里充满了“历史的痕迹”。

刚接手时，团队里没人愿意提它。每次有需求改动，开发同学都一脸苦相；测试同学也频频抱怨各种奇怪的“边界问题”；运维更是把它列入“高风险服务清单”。最夸张的是，有一次只是上线一个小按钮，结果影响了整个支付流程——用户付款后订单状态没更新，导致客服爆仓。

我知道，这不是普通的技术升级，而是一场技术债务的大清算。

---

问题描述：积重难返的老系统

系统基本情况

• 后端：Java Spring Boot + MyBatis，单体应用
• 前端：Vue.js + Webpack 打包，单页应用
• 数据库：MySQL（主从分离）+ Redis 缓存
• 部署方式：裸机部署，无自动化流水线

主要问题点

1. 代码结构混乱
   大量业务逻辑混杂在Controller层，Service层职责不清。部分模块存在重复实现，改一处牵一发动全身。

2. 缺乏单元测试和接口文档
   整个项目几乎没有单元测试，只有几个简单的集成测试。Swagger虽然还在跑，但很多接口根本没有注解说明，甚至返回结构都不统一。

3. 依赖版本落后严重
   Spring Boot版本停留在2.0，MyBatis是1.3，前端Vue版本为2.x，一些核心第三方SDK（如支付宝、微信支付）早已停止维护。

4. 性能瓶颈明显
   有些接口响应时间超过5秒，尤其是在高峰期。数据库慢查询频出，大量JOIN嵌套、没有合适的索引。

5. 安全漏洞隐患多
   没有XSS、SQL注入防护，部分接口还暴露敏感字段（比如用户手机号、地址），日志记录不完整。

6. 部署和监控几乎为零
   构建过程靠人工打包上传，没有CI/CD流程。线上运行异常只能靠日志手动排查，报警机制形同虚设。

---

解决方案：从哪里入手？

说实话，刚看到这些情况的时候，我也曾想过：重写是不是更简单？但很快打消了这个念头：

• 项目规模大（近80个核心表，前后端加起来几十万行代码）
• 业务逻辑复杂，很多隐藏规则仅存在于少数老员工心中
• 用户基数庞大，不能长时间下线或迁移

所以我决定采用渐进式重构的策略，而不是“推倒重来”。

第一步：建立基本防御体系

1. 先让系统“能看清楚”

• 搭建本地调试环境：之前团队基本都是直接改线上环境！这太危险了。我在本地搭起Docker容器环境，模拟生产数据库。
• 梳理代码调用链：用了ArchUnit静态分析工具扫描代码结构，初步摸清各模块依赖。
• 生成基础文档和测试用例：通过SpringDoc自动生成OpenAPI文档；结合Postman导出接口做基础回归测试。

2. 引入基础监控和日志

• 加入Sentry做错误追踪
• 用Prometheus + Grafana做系统指标可视化
• 接入ELK收集日志（尤其是请求入口和关键业务节点）

这一步虽然没解决根本问题，但至少让我们开始“看见问题”。

第二步：小范围模块抽离与重构

我们优先选了三个模块进行试点：

A. 订单创建模块（痛点最大）

• 原来的订单创建逻辑散落在多个Controller中，耦合度极高。
• 我们将其抽象为独立的OrderService，并引入领域驱动设计的思想，将实体对象、仓储、领域事件逐步拆分出来。
• 同时对慢查询做了优化，增加复合索引、减少不必要的JOIN操作。
• 测试方面补充了单元测试和Mockito模拟。

成果：

• 单次订单创建时间从5s降到了700ms左右
• 错误率下降80%
• 新增需求的开发效率提升3倍以上

B. 支付网关对接（安全高风险）

• 原有逻辑直接拼接URL参数，没有签名机制
• 对接的三方SDK已经不再支持新特性，无法应对最新的退款政策变更
• 重新封装成统一支付接口层，使用Apache HttpClient代替旧HTTPClient
• 实现自动签名、异步回调、失败重试机制

成果：

• 支付成功率提升10%
• 异常情况下的处理流程清晰可追溯

C. 权限模型重构

• 原有的权限控制分散在各个服务中，甚至有硬编码角色判断
• 使用Spring Security + JWT改造整体认证授权体系
• 实现RBAC模型，并将权限粒度细化到菜单级和按钮级

成果：

• 权限配置可视化，管理员可自主管理
• 减少权限相关的BUG数量90%+

第三步：基础设施升级

1. 后端框架升级

• 升级Spring Boot到2.7，MyBatis升至3.x，全面启用Lombok简化代码
• 统一使用CompletableFuture处理异步任务
• 引入MapStruct替代BeanUtils，提升转换效率

2. 前端工程化改进

• Webpack升级到v4，配置优化后构建速度加快30%
• Vue组件规范命名和生命周期管理
• 引入Vue Router懒加载，减小首屏体积
• 接入Vite作为开发服务器，热更新提速明显

3. 自动化体系建设

• 使用GitHub Actions搭建CI流水线，每次PR自动build+test
• 配置SonarQube做代码质量扫描
• 初步接入自动化部署（Ansible脚本）

---

技术选型的权衡与思考

为什么选择“渐进式重构”？

我们尝试过评估是否值得重写，但现实很骨感：

• 老业务中有很多隐性规则，比如某些特殊课程类型会触发特定优惠逻辑
• 用户行为数据难以复刻，一旦新系统上线可能引发意料之外的后果
• 开发资源有限，不能牺牲日常业务需求去做“看不见回报”的重写

所以，我们选择了“稳扎稳打”的路线：每次只动一小块，确保每一步都有明确收益。

微服务 vs 单体架构？

很多人一听老项目就会想到微服务拆分。但在当时的情况下，我认为并不合适：

• 拆分本身就需要大量的调研和通信成本
• 运维能力还没跟上，拆完之后可能反而更容易出问题
• 当前架构的瓶颈主要在内部逻辑，而非并发或扩展性

所以最终的决定是：先做强内功，再考虑拆分。

---

实施效果与收益

经过半年的努力，整个项目的健康度有了明显改善：

指标	改造前	改造后	提升
日均报错数	1200+	<150	下降85%
核心接口平均耗时	2.8s	0.7s	提升4倍
新需求平均开发周期	7天	2.5天	快速交付能力增强
团队协作满意度	较差	明显好转	——
技术面试通过率	低（因系统复杂）	高（文档清晰）	人才吸引力增强

更重要的是，整个团队的士气发生了变化。以前提到这个系统大家就叹气，现在反而越来越多工程师主动参与优化，甚至有新人愿意第一个接手这个模块。

---

总结：我的几点经验分享

1. 别急着重写，先搞明白“它为什么活着”

每个老项目之所以能存活多年，一定有它的价值。我们要做的不是急于否定，而是理解它背后的“生存逻辑”。

2. 技术债务治理，一定要从业务目标出发

不要为了“好看”而重构。所有改动都要对齐业务价值：提高稳定性、降低维护成本、提升交付速度，这才是技术债治理的根本目的。

3. 文档比代码更重要

重构过程中，我花了很多时间整理文档。事实证明，这是非常值得的。后来新同事上手快得多，交接也顺利。

4. 尽早引入质量保障机制

哪怕是最简单的UT和静态检查，也能帮助你避免很多低级错误。别等出了问题才想起来补，那时候代价更大。

5. 可视化是信心建设的关键

无论是性能指标还是错误趋势图，都能让你更有底气地推进下一步动作。而且团队也能直观感受到努力的价值。

6. 慢就是快，稳定胜于一切

有时候看似“进步慢”，其实是走得更远。重构就像爬山，不是谁冲得最快就能登顶，而是谁更能坚持、走得稳妥。

---

写在最后：给同行的一点建议

技术债不是一天欠下来的，也不会在一两个月内还清。它更像是慢性病，需要持续关注和耐心调理。如果你正在面对类似的老项目，不妨试试这几个问题问问自己：

• 它的核心痛点是什么？
• 最值得优先改善的模块是哪个？
• 有没有最小可行的重构路径？
• 能否量化你的投入产出比？

很多时候我们总想着“我要做得完美”，却忘了“做些改变”比“等待完美”更重要。

最后想说一句：“技术债”听起来沉重，但它也是推动技术成长的重要契机。真正的好系统，不是一开始设计得多么好，而是经历了多少风雨之后，依然能够健步前行。

希望这篇文章能给你带来一点启发。如果你也在经历类似的挑战，欢迎留言交流，一起共勉！