此條目需要擴充。 (2015年5月14日)请協助改善这篇條目，更進一步的信息可能會在討論頁或扩充请求中找到。请在擴充條目後將此模板移除。
技术负债（英語：Technical debt），又譯技術債，也稱為設計負債（design debt）、程式碼負債（code debt），是程式設計及軟體工程中的一個比喻。指开发人员为了加速软件开发，在应该采用最佳方案时进行了妥协，改用了短期内能加速软件开发的方案，从而在未来给自己带来的额外开发负担。這種技術上的選擇，就像一筆債務一樣，雖然眼前看起來可以得到好處，但必須在未來償還。軟體工程師必須付出额外的時間和精力持續修復之前的妥协所造成的問題及副作用，或是進行重構，把架構改善為最佳實作方式。
1992年，沃德·坎宁安首次将技术的复杂比作为负债。
第一次发布代码，就好比借了一笔钱。只要通过不断重写来偿还债务，小额负债可以加速开发。但久未偿还债务会引发危险。复用马马虎虎的代码，类似于负债的利息。整个部门有可能因为松散的实现，不完全的面向对象的设计或其他诸如此类的负债而陷入窘境[1]。
技术债务的分类[编辑]
技术债务的四象限分类
鲁莽Reckless
谨慎Prudent
故意Deliberate
我们没有时间做设计
我们必须马上交付，后果以后再说
疏忽Inadvertent
什么是分层（设计）？
现在我们才知道该如何做了
马丁·福勒提出了把技术负债分为四个象限[2]。
常见的技术债务的原因有：
不充足的事前定义，从而需求仍然在开发过程中被定义，开发在设计之前就已经开始。这种做法的目的是节约时间，但常不得不以后返工。
商务压力。商务角度需要在必须的改变完成之前就发布产品。因此开发的技术债务包括那些待完成的改变。[3]:4[4]:22
缺少流程或理解，从而商务上对技术债务不了解，不考虑后果就做出决策。
紧耦合组件。功能不是模块化，软件不够灵活应对商务上的变化。
缺乏测试套件。这刺激了快速高风险“凑活式”的修复bug。
缺少文档。写代码但没有必要的支撑性文档。[3]
缺乏合作。知识没有得到共享，对新手缺乏监督辅导。
在两个或多个分支上平行开发而累积了技术债务。由于工作最终需要合并两个分支的代码，拖延越晚，需要工作代价越大。
拖延做重构 – 重构拖延越晚，需要修改的代码越多。[4]:29
缺少与标准对齐。工业标准的特性、框架、技术被忽视。最终也必将遵从标准，做得越早代价越小。[3]:7
缺少知识。开发者并不知道如何写精致的代码。[4]
缺少所有权。外包的软件最终要让自己的工程师去重构或重写源代码。
技术领导力差，未深思熟虑的命令通过命令链传达下来，增加了技术债务，而不是减少它。
最后一分钟规范改变。这有可能渗透到整个项目中，没有时间或预算通过文档或检查来发现它们。
参见[编辑]
大泥球 (编程)
参考资料[编辑]
^ Ward Cunningham. The WyCash Portfolio Management System. 1992-03-26 [2008-09-26]. （原始内容存档于2008-12-23）.
^ Fowler, Martin. Technical Debt Quadrant. [20 November 2014]. （原始内容存档于2013-02-02）.
^ 3.0 3.1 3.2 Girish Suryanarayana; Ganesh Samarthyam; Tushar Sharma. Refactoring for Software Design Smells: Managing Technical Debt. Elsevier Science. 11 November 2014: 3 [2019-02-19]. ISBN 978-0-12-801646-6. （原始内容存档于2021-05-26）.
^ 4.0 4.1 4.2 Chris Sterling. Managing Software Debt: Building for Inevitable Change (Adobe Reader). Addison-Wesley Professional. 10 December 2010: 17. ISBN 978-0-321-70055-1.