权威解读什么是技术负债？ - martinfowler.com

软件系统是容易的积聚一些累赘 cruft : 内部质量不高，导致其比预想更难进行修改和进一步扩展系统。技术债务是沃德坎宁安（Ward Cunningham）创造的一个比喻，它描述了如何考虑处理这种问题，将其视为金融债务，增加新功能所需的额外成本是债务利息。

想象一下，我的代码库中有一个令人困惑的模块结构。我需要添加一个新功能。如果模块结构清晰，那么我需要四天时间才能添加这个功能，但是这需要六天时间。两天的差额就是你要付出的债务利息。

关于债务比喻最吸引我的是它如何促使我如何处理这个问题。我可能需要五天时间来清理模块化结构，移除那个残骸，暗地了其实支付了利息。如果我只为这一个功能就进行重构，那就没有多大收获，因为我需要9天而不是6天。但是，如果我有两个更相似的功能出现，那么我将通过首先删除累赘cruft来加快速度。

这样说，这听起来像是处理数字的简单问题，任何有电子表格的经理都应该找出选择。遗憾的是，由于我们 保持了生产力 ，因此这些成本都不是客观可衡量的。我们 可以估计 完成一个功能需要多长时间， 估计 如果移除这个功能可能会是什么样的，并  估计 移除这个功能的成本。但这种估计的准确性非常低。

鉴于此，通常最好的方法是做我们通常做的金融债务，逐步还债。碰到第一个功能时，我将花费额外的几天来删除一些残余累赘。这可能足以将未来重构时间降低一天，重构仍然需要花费额外的时间，但是通过删除这个问题我将使这个代码的未来更改变得更便宜。

像这样逐步改进的巨大好处是，它自然意味着我们花费更多的时间来消除我们经常修改的那些区域中的累赘，这正是代码库中我们最需要删除的累赘部分。

将此视为支付利息与支付本金可以帮助决定解决哪个问题：如果我有一个可怕的代码库区域，这是一个改变的噩梦，如果我不必修改它就不是问题。当我必须使用软件的那一部分时，我才会触发利息支付（这是一个比喻崩溃的地方，因为经济利息支付是由时间推移引发的），这样苛刻但稳定的代码区域可以独自存在。相比之下，代码中 高活跃区域需要对累赘态度必须采取零容忍态度，因为支付的利息非常高 。这一点尤为重要，因为在开发人员进行更改而不关注内部质量的情况下，不可避免地会积累起来 - 更多的变化，更大的风险。

债务的隐喻有时被用来证明忽视内部质量反而是正当的。争论的焦点是，需要时间和精力才能阻止累赘的累积，如果迫切需要新的功能，那么也许最好承担债务，接受支付利息以便将来必须管理这笔债务。

这里的危险是大多数时候这种分析做得不好！ 累赘Cruft具有快速影响，会快速降低所需的新功能的开发效率。

如果团队为了加快交付时间，而忽略首先将内部质量提高到更高的水平，这样做的团队最终会把他们所有的信用卡都用掉（爆卡，债务危机），

在这里，债务比喻往往会让人误入歧途，因为软件质量的动态与金融贷款的动态并不完全相符。承担债务以加速交付只有在您停留在 DesignStaminaHypothesis 的设计支付线以下时才有效，并且团队达到这条红线只是几周时间而不是几个月。

进一步阅读

• 据我所知，沃德首先在 1992年OOPSLA 的经验报告中介绍了这个概念。它也在 维基 上讨论过。
• 沃德坎宁安有一个 视频谈话 ，他讨论了他创造的这个比喻。
• Dave Nicolette通过对我称之为  谨慎故意债务 的 精细案例研究 扩展了Ward对技术债务的看法
• 一些读者发来了一些同样好的名字。David Panariti将丑陋的编程称为 赤字编程 。显然，他最初在几年前开始使用它符合政府政策; 我想现在再次自然了。
• 斯科特伍德建议“ 当技术水平超过产品基础时， 技术通胀 可能会被视为失去的基础，以至于它开始失去与行业的兼容性。这种情况的例子将落后于版本的语言到你的代码不再与主流编译器兼容的程度。“
• 史蒂夫麦康奈尔 在这个比喻中提出了几个好点，特别是如果保持你的意外债务，你会有更多的空间在有意义的情况下有意承担债务。我也喜欢他的最低支付概念（这对于修复嵌入式系统而不是网站的问题非常高）。
• Aaron Erickson谈到 安然融资 。
• Henrik Kniberg认为 ，较旧的技术债务导致了最大的问题，而且定性债务上限有助于管理它。
• Erik Dietrich讨论了 技术债务 的 人力成本 ：团队内inf，萎缩技能和 自然 减员。

相关：

吐槽“技术债务”