软件系统往往会堆积垃圾 -内部缺陷，与理想代码相比，内部缺陷使其难以进一步修改和扩展系统。 技术债务是沃德·坎宁安（Ward Cunningham）发明的一个隐喻。 她通过类比财务贷款的方式解释了如何感知这种垃圾。 增加新功能所需的额外工作是贷款利息。



想象一下，在我的代码库中，有一个结构混乱的模块。 需要添加新功能。 如果结构清晰，则工作将需要四天，但是带有此垃圾将花费六天。 两天内的差额-这是债务的利息。

在债务隐喻中，吸引我最多的是对服务或消除债务成本的清楚理解。 我可以花五天时间清理模块化结构，清除垃圾，并隐喻地支付“贷款人”的费用。 如果为此功能执行此操作，我将失败，因为我将花费9天而不是6天。 但是，如果再有两个这样的功能，那么删除垃圾将更有利可图。

通过这种表述，任务就变成了纯粹的数学。 任何拥有电子平板电脑的经理都可以解决。 不幸的是，我们无法衡量绩效 ，因此无法客观地衡量成本。 我们可以粗略地估算出开发该功能需要花费多长时间，删除垃圾后需要花费多长时间-并假设删除它的成本。 但是这种估计的准确性很低。

因此，通常最好的选择是对金融债务做我们通常要做的事情：逐步偿还本金。 在第一个功能中，我将花费额外的几天来删除一些垃圾。 这可能足以减少债务利息，以便将来可以在一天之内偿还。 这仍然是额外的时间，但是随着垃圾的清除，未来的更改变得更加便宜。 不断改进的最大优势在于，我们自然会花更多的时间在经常变化的区域清除垃圾。 这些正是代码库中最需要进行垃圾处理的区域。

将利息支付与本金支付的比较有助于确定要处理的垃圾种类。 如果我在代码库中有一些特别糟糕的地方，那么事实证明，删除垃圾无利可图，问题就消失了。 仅当您必须使用软件的这一部分时才支付利息（在这个地方，隐喻有点la脚，因为您总是必须用银行贷款来支付）。 因此，可以将噩梦般的稳定代码区放在一边。

与代码的稳定部分不同，活动频繁的区域要求对垃圾的容忍度为零，因为那里的利息支付非常高。 这一点尤其重要，因为垃圾会堆积在开发人员进行更改而不关注质量的地方：更改越多，垃圾的风险就越大。

有时会使用债务隐喻来证明质量欠佳的代码。 有观点认为，质量代码需要更多的时间和精力。 如果您急需新功能，最好先承担债务，以后再处理

这里的危险是这种分析经常是错误的。 垃圾很快就开始造成危害，从而减慢了新功能的引入。 结果，开发人员超出了信用额度，并且比立即花时间提供更高质量的产品晚了发布产品。 在这里，这种隐喻常常会误导人们，因为技术债务的动态实际上并不对应于金融贷款的动态。 假设为加快产品发布而背负的债务只有在您以架构可持续性为前提而未达到设计回报线的情况下才有效 ，并且开发人员会在数周而不是数月的时间内完成这项工作。



有关是否应将各种垃圾视为债务的辩论经常举行。 在我看来，在这里考虑是否有意识地，合理地或不计后果地履行职责是很有用的。 于是出现了技术债务平方 。

进一步阅读

据我所知，沃德在1992年的OOPSLA报告中首次引入了这一概念。 Wiki上也对此进行了讨论。

沃德·坎宁安（Ward Cunningham）讨论他的隐喻时有一段录像 。

戴夫·尼科莱特（Dave Nicolette）通过提供我所谓的合理故意债务的一个很好的例子 ，扩展了沃德对技术债务的看法。

一些读者提出了其他有效的隐喻。 大卫·潘纳里蒂（David Panarity）将低质量的开发称为编程短缺 。 显然，他几年前开始使用这个术语，因为它与政府政策一致。 我想现在又很重要了。

斯科特·伍德（Scott Wood）建议，当目前的技术水平超过您的产品水平而逐渐脱离环境时，将技术膨胀视为土壤流失。 程序在该语言的版本中落后到一定程度，以致该代码不再与主要编译器兼容。”

史蒂夫·麦康奈尔（Steve McConnell）在隐喻中强调了几个优点。 尤其是，由于减少了无意识的债务，在有帮助时留出了更多有意接受债务的空间。 我也喜欢他制定的最低付款额（该金额太高，无法解决嵌入式系统中的问题，而不能解决现场问题）。

亚伦·埃里克森（Aaron Erickson）谈到了为安然（Enron）融资 。

亨里克·克尼伯格（Henrik Kniberg）认为 ，过去的技术债务是造成最大问题的原因，因此，建立高质量的债务上限以使其更易于管理是明智的。

埃里克·迪特里希（Eric Dietrich）讨论了由于技术债务而造成的人员损失 ：团队斗争，技能退化和倦怠。

编辑

这篇文章最初发表于2003年10月1日。 我在2019年4月完全重写了它。