复盘：一次被迫停更的迭代
四月那次版本上线前夜，我盯着依赖图发呆——一个订单核心模块被 27 个地方引用，改一处要回归 40 个用例，测试同学直接摆烂说「这版先别动它」。这不是第一个被技术债拖住的需求。入行第六年，我越来越觉得，技术债不是写烂代码，是「明知该改但一直没改」的累积。
债务识别：先把账算清楚
我们拉了一份技术债清单，按来源分了三类：
- 代码坏味道：超长方法、上帝类、重复逻辑。用 SonarQube 扫，标了 312 处 blocker。
- 架构债：模块环形依赖、共享数据库、同步调用链过长。这类危害最大但最难量化。
- 依赖债：Spring Boot 2.7 还在跑、Log4j 老版本、一个三年没更新的内部 SDK。
优先级排序：不是所有债都要还
关键看两个维度——影响面（改它能解放多少需求）和偿还成本（工时、风险）。我们用了个简单的四象限：
| 影响面＼成本 | 低 | 高 |
|---|---|---|
| 高 | 立刻做（高杠杆） | 排期拆分 |
| 低 | 顺手做 | 先放着 |
那个被 27 处引用的订单模块正好是「高影响、高成本」，我们没碰它本体，而是先抽出防腐层（ACL），把 27 个调用方陆续迁到新接口，本体改造风险就被隔离了。
改造节奏：把债还进迭代里
最致命的做法是「停业务专门还债」，基本都会被排期砍掉。我们的规则是：每个迭代强制划出 15% 工时给技术债，且债和feature绑定——要做新需求的地方，顺手把那块代码整理掉。这样还债不占额外排期，PM 也能接受。
比如做优惠券需求时，发现券规则散落在 6 个 if-else 里，干脆借机抽成规则引擎，工时记在需求头上，技术债顺手清了。
风险控制：每次改造都有逃生舱
- 开关：新旧逻辑用配置开关并存，出问题秒回滚。
- 灰度：按用户百分比放量，监控错误率和耗时。
- 度量：用「需求平均交付周期」和「线上故障数」反向验证还债有没有效果。半年下来交付周期从 11 天降到 7 天。
小结
技术债治理不是运动式清欠，是把它变成日常节奏。识别靠度量、排序靠影响面、偿还靠和 feature 绑定、兜底靠开关灰度。别追求一次性还清，那不现实，也最容易翻车。