技术债：为什么团队明知故犯
「这块代码欠了太多技术债」是团队里最常被说、也最少被解决的一句话。原因很简单：说这句话的人，通常不是要动手的人。
一、四种真实成因
| 成因 | 当时的选择理由 | 代价 |
|---|---|---|
| 赶上线 | 截止日期不可协商 | 后面每次改动都要绕开它 |
| 需求不确定 | 先做快的，等验证 | 验证后没人回头重构 |
| 知识缺失 | 当时不知道更好的做法 | 后期学习成本转成维护成本 |
| 人员流动 | 写的人走了，没人敢动 | 模块变成黑盒 |
四类里只有第三类是「可以避免」的，其他三类都是权衡。把它们一律叫做「债」，容易让人误以为只是懒惰。
二、什么债该还，什么不该还
不是所有债都要还。判断标准是这块代码未来的改动频率：
- 高频改动 + 高复杂度：立刻还，不还就会持续拖慢每一次迭代；
- 低频 + 高复杂度：不碰。为了「整洁」去重构一个三年没改过的模块，是最典型的浪费；
- 高频 + 低复杂度：顺手改，不必立项；
- 低频 + 低复杂度：别管。
这条判断能砍掉一半「重构计划」。
三、把债写进需求，而不是写进抱怨
有效的做法不是「争取重构时间」，而是把重构包装成业务需求的必要部分：
差的表述：这个模块太烂了，我要时间重构
好的表述：这次要加的功能，在现有结构上需要改 12 个文件；
先合并 3 个重复逻辑，只需要改 4 个，多花 2 天，
之后同类需求每次都能省 1 天第二种说法才有机会被批准，因为它讲的是投入产出，不是审美。
四、三个低成本的习惯
- 改动必留注释：为什么这么写、绕开了什么坑，比代码本身更值钱；
- 每次改动顺手清理一处：删一个没用的开关、合并一段重复逻辑，成本几乎为零；
- 记录「为什么没这么做」：很多后来者重复踩坑，是因为不知道当初为什么排除了更简单的方案。
五、什么时候技术债会变成事故
三个信号出现时，说明已经不是「债」而是「风险」了：
- 没人敢改：改动前要开会讨论一小时；
- 改一次坏一次：修 A 导致 B 挂，说明耦合已经失控；
- 新人上手要两周：知识没有沉淀在代码和文档里。
这三个信号出现时，投入是必须的，因为它在直接吞噬产能。
六、AI 工具带来的变化
代码生成工具降低了「写」的成本，但也加速了「生产债」——自动生成的代码如果没有结构约束，重复逻辑会更多。所以工具越强，越需要架构约束和代码审查。
关于人机分工的边界，见 AI 编程助手改变了什么，没改变什么。
相关阅读
版权声明：如无特殊标注，文章均为本站原创，转载时请以链接形式注明文章出处。
评论