技术负债

技术负债（英语：Technical debt），又译技术债，也称为设计负债（design debt）、代码负债（code debt），是程序设计及软件工程中的一个比喻。指开发人员为了加速软件开发，在应该采用最佳方案时进行了妥协，改用了短期内能加速软件开发的方案，从而在未来给自己带来的额外开发负担。这种技术上的选择，就像一笔债务一样，虽然眼前看起来可以得到好处，但必须在未来偿还。软件工程师必须付出额外的时间和精力持续修复之前的妥协所造成的问题及副作用，或是进行重构，把架构改善为最佳实现方式。

1992年，沃德·坎宁安首次将技术的复杂比作为负债。

第一次发布代码，就好比借了一笔钱。只要通过不断重写来偿还债务，小额负债可以加速开发。但久未偿还债务会引发危险。复用马马虎虎的代码，类似于负债的利息。整个部门有可能因为松散的实现，不完全的面向对象的设计或其他诸如此类的负债而陷入窘境。

技术债务的分类

技术债务的四象限分类

	鲁莽Reckless	谨慎Prudent
故意Deliberate	我们没有时间做设计	我们必须马上交付，后果以后再说
疏忽Inadvertent	什么是分层（设计）？	现在我们才知道该如何做了

马丁·福勒提出了把技术负债分为四个象限。

常见的技术债务的原因有：

• 不充足的事前定义，从而需求仍然在开发过程中被定义，开发在设计之前就已经开始。这种做法的目的是节约时间，但常不得不以后返工。
• 商务压力。商务角度需要在必须的改变完成之前就发布产品。因此开发的技术债务包括那些待完成的改变。
• 缺少流程或理解，从而商务上对技术债务不了解，不考虑后果就做出决策。
• 紧耦合组件。功能不是模块化，软件不够灵活应对商务上的变化。
• 缺乏测试包。这刺激了快速高风险“凑活式”的修复bug。
• 缺少文档。写代码但没有必要的支撑性文档。
• 缺乏合作。知识没有得到共享，对新手缺乏监督辅导。
• 在两个或多个分支上平行开发而累积了技术债务。由于工作最终需要合并两个分支的代码，拖延越晚，需要工作代价越大。
• 拖延做重构 – 重构拖延越晚，需要修改的代码越多。
• 缺少与标准对齐。工业标准的特性、框架、技术被忽视。最终也必将遵从标准，做得越早代价越小。
• 缺少知识。开发者并不知道如何写精致的代码。
• 缺少所有权。外包的软件最终要让自己的工程师去重构或重写源代码。
• 技术领导力差，未深思熟虑的命令通过命令链传达下来，增加了技术债务，而不是减少它。
• 最后一分钟规范改变。这有可能渗透到整个项目中，没有时间或预算通过文档或检查来发现它们。

参见

• 大泥球 (编程)