技术债的度量与偿还
技术债是借来的开发速度：为了赶上线选择次优方案，代价是后续每次改动的额外成本。负债本身不是错，失控的负债才是。
债的三种来源
- 有意的：赶上线明确记下「先这样，Q3 还」，有记录有计划——这是健康的债；
- 无意的：当初的正确选择随需求变化变成负担（单机部署在用户过万后成了瓶颈）——这是环境的债；
- 无知的：不知道有更好方案写出来的代码——这是最贵的债，只能靠评审和培训预防。
让利息可见
技术债难管是因为「利息」分散且无感。把它显式化：
- 热点分析：统计 git 提交频率 × 代码复杂度。改动最频繁且最难改的模块，就是付利息最多的地方——优先偿还它们；
- bug 分布：最近三个月的线上问题按模块统计，聚集处通常就是债所在；
- 变更成本记录：每次需求评估时，把「因为旧结构多花的时间」记下来。累计数字比抽象口号更有说服力。
偿还的节奏
顺手偿还（ Boy Scout 规则的边界版）：改到相关代码时，允许额外 10-20% 的时间做局部清理。前提是有测试保护，否则「顺手改」是引入新债。
专项偿还：对热点模块立项，按重构的小步节奏推进。排期时用利息数据说话：
搜索模块近半年 14 次需求，平均每次因旧结构多花 1.5 天 ≈ 21 人天/半年。重构预估 12 人天，回报周期不足半年。
不偿还的债也要管理：明确标注「此债不还」及原因（模块即将下线、影响面可控）。记录本身就能阻止它被反复讨论。
防止新债的三道闸
- 评审清单里的「这算不算新债」检查项；
- 新方案评审时必须包含「如果时间翻倍你会怎么改」——差额就是本次借债的规模，记录在案；
- 定期（每季度）回顾债清单，偿还一部分、复核一部分。
技术债讨论里最没用的话是「代码太烂要重写」。有用的是：哪一块、利息多少、还多少钱、什么时候还清。