技术债 (Tech Debt) 不是坏习惯的产物

技术债 (Tech Debt) 不是坏习惯的产物

是每一个「情有可原」叠加的结果

最可怕的技术债，不是你知道的那种
是你以为还没有，但其实已经很深了

1/8

技术债有两种
「显性债」你知道它在那里
「TODO: 这里需要重构」
「隐性债」你不知道它存在 直到加新功能的时候，才发现要先还三个月的债

隐性债比显性债危险 10 倍

2/8

隐性债是怎么来的

每次「先这样，之后再改」
每次「现在没时间，下个 sprint」
每次「这个场景概率很低，先不处理」

每一笔单独看，都合理
加在一起，就是一个谁也不知道有多深的坑

3/8

我犯过最大的错误

不是允许债存在
是允许债「不可见」

团队里每个人都知道某些地方很烂
但没有人把它写出来，量化它，让所有人一起看到

看不见的债，永远还不完
因为你没法为一个不存在的东西排优先级

4/8

现在的做法：每季度做一次「债务审计」

不是 code review
是专门问一个问题

「如果下个季度要加 X 功能，哪些地方会先拖住我们？」

把答案列出来，每条估算影响范围
然后整个团队一起看

5/8

债务审计有几个关键操作

写出来，不只是说出来
说出来会被遗忘，写出来才有压力

量化影响，不只是「这里很乱」
「这里每次改动要额外花 3 天」才是可以排优先级的数据

让团队集体看到，不只是 tech lead 知道
债是集体的，还债也需要集体认账

6/8

技术债的另一个误区

认为「还清」是目标

真正的目标是「债在可控范围内」
零债的系统，要么功能很少，要么没有在快速迭代

合理的债，是用未来的时间换现在的速度
关键是你清楚自己借了多少，借的是哪里

7/8

对独立开发者来说，这件事更重要

一个人的系统，债不透明的代价更大
因为没有队友帮你发现「这里快撑不住了」

我现在每个月花一小时，只做一件事
把所有「之后再改」列出来，看总量
总量超过一个阈值，下个月先还债再加功能

8/8

总结

技术债不是问题
看不见的技术债才是

每季度让债可见
量化影响
集体认账

做到这三件事
债不会消失，但它不会在你不知道的地方把你压垮