技术债务

软件系统容易积累劣质代码——内部质量的缺陷，这使得修改和扩展系统变得比理想情况下更加困难。技术债务是由 Ward Cunningham 创造的一个比喻，它构建了如何处理这种劣质代码的思考方式，将其视为一种金融债务。添加新功能所需的额外工作就是偿还债务的利息。

假设我的代码库中有一个混乱的模块结构。我需要添加一个新功能。如果模块结构清晰，那么我需要四天时间来添加该功能，但由于这种劣质代码，我需要六天时间。这两天的差异就是债务的利息。

债务比喻最吸引我的一点是，它如何构建了我对如何处理这种劣质代码的思考方式。我可以花五天时间清理模块结构，移除劣质代码，这就好比是偿还本金。如果我只为这一个功能这样做，那就没有收益，因为我需要花费九天而不是六天。但如果我还有两个类似的功能要做，那么我先移除劣质代码最终会更快。

这样说来，这听起来像是一个简单的数字计算问题，任何拥有电子表格的经理都应该弄清楚这些选择。遗憾的是，由于我们无法衡量生产力，所有这些成本都无法客观衡量。我们可以估计完成一项功能需要多长时间，估计如果移除劣质代码会是什么样子，以及估计移除劣质代码的成本。但我们对这种估计的准确性相当低。

鉴于此，通常最好的方法是像我们通常处理金融债务那样，逐步偿还本金。在第一个功能上，我会额外花几天时间来移除一些劣质代码。这可能足以将未来增强的利率降低到一天。这仍然需要额外的时间，但通过移除劣质代码，我正在降低未来更改此代码的成本。像这样逐步改进的最大好处是，它自然意味着我们会花更多的时间来移除我们经常修改的那些区域中的劣质代码，而这些区域正是代码库中最需要移除劣质代码的区域。

将其视为支付利息与偿还本金有助于决定要处理哪些劣质代码。如果我有一个糟糕的代码库区域，一个难以更改的区域，那么如果我不必修改它，那就不是问题。只有当我必须处理软件的那一部分时，我才会触发利息支付（这是比喻失效的地方，因为金融利息支付是由时间的推移触发的）。因此，可以放任那些劣质但稳定的代码区域。相比之下，高活动区域需要对劣质代码采取零容忍的态度，因为利息支付高得令人难以承受。这一点尤其重要，因为劣质代码会在开发人员在不关注内部质量的情况下进行更改的地方累积——更改越多，劣质代码累积的风险就越大。

债务的比喻有时被用来为忽视内部质量辩护。其论点是，阻止劣质代码的积累需要时间和精力。如果需要紧急添加新功能，那么也许最好是承担债务，并接受将来必须管理这笔债务。

这里的危险在于，大多数情况下，这种分析做得并不好。劣质代码会产生快速的影响，减缓急需的全新功能的开发速度。这样做的团队最终会刷爆他们所有的信用卡，但交付时间仍然比他们努力提高内部质量要晚。在这里，这个比喻常常会误导人们，因为其动态与金融贷款的动态并不真正匹配。只有当你保持在设计耐力假说的设计收益线以下时，承担债务以加快交付速度才有效，而团队会在几周而不是几个月内触及这条线。

关于不同类型的劣质代码是否应该被视为债务，一直存在着争论。我发现，考虑债务是否是故意承担的，以及它是谨慎的还是鲁莽的，这很有用——这让我想到技术债务象限。