技术债的利息长什么样
技术债不是「代码写得丑」，而是「以后每次改动都要多付的那部分」。判断标准是可测量的：改一行要动几个文件、跑多久测试、有几处需要同时改。
把技术债当道德问题讨论，永远不会有结论。它是个经济问题：借了一笔，之后每次操作都在付利息。
利息是可量化的
| 症状 | 可测量的指标 |
|---|---|
| 改一处要动很多文件 | 一次改动的文件数 |
| 不敢改 | 有没有测试能证明没改坏 |
| 加一个字段要改五个地方 | 同一个概念的重复定义处数 |
| 构建越来越慢 | 从改完到看到结果的秒数 |
| 新人上手慢 | 从 clone 到提交第一个修复的天数 |
把症状翻译成数字，债务就从观点变成了事实。
本金与利息的区别
- 本金：重写那部分的成本，一次性
- 利息：每次改动多花的时间，持续发生
判断该不该还，比较的是「本金」与「未来利息总和」。
重构成本：3 天
每加一个字段多花：2 小时
预计还要加：20 个字段 → 40 小时 ≈ 5 天
结论：现在重构更划算如果那个模块三个月内不会再动，利息就是零，不该还。技术债的危险不在于存在，而在于它在高利息区堆积。
高利息区通常在哪
- 被所有人依赖的核心类型：改一次影响全站
- 每次发版都要手动做的步骤：漏一步就出事
- 没人敢动的启动脚本：出问题时无法排查
- 测试覆盖为零的关键路径：改动全靠运气
前两条是典型的复利：不仅每次都付，而且随规模变大而变贵。
有意借债是可以的
「先上线，一周后回来补」是合法决策，前提是写下来：
TODO(债务): 支付回调现在同步处理，超时会丢单。
影响: 高峰期可能丢单。
偿还: 改成队列异步，约 1 天。
期限: 上线后两周内。关键是「期限」。没有期限的 TODO 就是永久债务，而且没人会记得它当时是权衡过的，后来的人只会觉得这代码莫名其妙。
别把「不好看」当债
命名不优雅、函数略长、注释少 —— 这些如果没有增加未来改动成本，就不是债，是风格。把它们当债会让真正的债被淹没。
判据只有一条：以后每次改动，它让你多付了多少。付不出的部分才值得还。
评论
…