Ward Cunningham 在 1992 年提出「技术债务」这个概念时，他可能没想到三十年后这个词会成为每一个技术团队的噩梦。技术债务不像金融债务那样可以精确计算，它更像是一种熵——在看不见的地方悄悄增长，直到系统变得不可维护。

技术债务不是一种债

很多人把技术债务理解为「欠下的代码质量」，觉得只要花时间重构就能还清。这个理解有一个根本性的错误：技术债务不是贷款，而是复利。

金融债务：
  借 100 万，年利率 5%，每年还 5 万利息
  债务总额是确定的，还款计划是可预测的

技术债务：
  写了一段快速但丑陋的代码来赶 deadline
  第一个月：需要在这段代码旁边加个功能 → 多花了 2 小时
  第三个月：新人入职看不懂这段代码 → 多花了 2 天
  第六个月：这段代码的 Bug 引发了线上事故 → 多花了 1 周
  第十二个月：这段代码和其他模块的耦合太深，无法重构 → 被迫放弃

技术债务的利息不是线性的，而是指数增长的

这就是为什么技术债务不能「等有空了再还」——因为等你有空的时候，利息可能已经超过了本金。

技术债务的四种类型

Martin Fowler 在《Refactoring》中把技术债务分为四个象限：

                    鲁莽的                审慎的
              ┌──────────────────┬──────────────────┐
    故意的     │ "我们不需要测试"  │ "我们知道这里耦合   │
              │ "先 copy paste  │  太紧，但现在重构   │
              │  以后再重构"     │  会延误发布，下个月  │
              │                 │  专门处理"         │
              ├──────────────────┼──────────────────┤
    无意的     │ "什么是分层？"    │ "我们现在才理解    │
              │ "把 SQL 写在     │  应该怎么做"       │
              │  Controller 里"  │（随着认知深入发现   │
              │                 │  之前的设计有问题）  │
              └──────────────────┴──────────────────┘

鲁莽且故意的债务最危险——团队明知故犯，而且不考虑后果。