比喻

Ward Cunningham 在 1992 年提出这个概念：

为了快速交付，走了"捷径"——就像借了一笔钱。

这笔钱让你可以更快拿到想要的东西，但要付利息：后续在这部分代码上工作的成本会增加。

技术债 = 为了短期速度而牺牲的长期质量。

常见形式

一、设计债：架构不合理，模块耦合严重，改一处要动多处。

二、代码债：命名混乱、重复代码、超长函数、缺乏注释。

三、测试债：没有测试或测试覆盖不足，改动不敢下手。

四、文档债：没有文档或文档过时，新人上手困难。

五、依赖债：使用了过时、不再维护、或有已知漏洞的第三方库。

六、基础设施债：部署流程手工化、缺少监控和告警、环境不一致。

并非全是坏事

技术债不总是错的。

有些债是有意的、战略性的：

  • 为了验证一个产品假设，先用最快的方式做出来；
  • 赶一个关键的时间窗口；
  • 某个模块可能很快会被废弃，不值得投入高质量实现。

关键区别：

  • 审慎的、有意识的债：知道自己在欠债，有计划偿还；
  • 鲁莽的、无意识的债：不知道自己在欠债，也没有偿还计划。

后者才是真正危险的。

利息是怎么产生的

技术债的成本不是立即显现的，而是随时间累积：

  • 在一个设计糟糕的模块上新增功能，耗时是新设计的数倍；
  • 没有测试的代码，每次改动都要手工回归，且容易引入新的 bug；
  • 过时的依赖最终会强制升级，届时可能要一次性完成多年的变更。

最危险的情况：债累积到某个临界点，系统的修改成本超过了重写成本——这时团队往往会选择"重写"，而重写本身风险极高。

如何管理

一、让债可见。

把已知的技术债记录下来（如用 issue tracker 标记），定期审视。

看不见的债无法管理。

二、在迭代中预留偿还时间。

常见的做法是：每个迭代预留 15%–25% 的时间用于偿还技术债、重构和改进。

三、"童子军规则"（Boy Scout Rule）：

每次经过一段代码，都让它比你来时干净一点。

不需要专门立项，而是把改进融入日常工作——改一个 bug 时顺便清理相关的混乱代码。

四、在代码评审中把关。

评审是防止新债产生的最有效环节。

五、量化影响。

向非技术干系人解释技术债，最好的方式是关联到业务影响：

  • "这个模块改一个需求需要 3 周，而设计良好的情况只需要 3 天"；
  • "上次线上事故中，有 40% 的排查时间花在定位一个没有日志的模块"。

一个平衡

过度追求"零技术债"也是问题。

有些代码不需要完美——如果它稳定、很少改动、能正常工作，投入重构的收益可能低于成本。

判断标准：这段代码的变更频率和重要性。

  • 高频修改、核心路径的代码 → 要保持高质量；
  • 低频、边缘的代码 → 可以容忍一些"债"。

说明：本文为软件工程实践的知识整理。