技术负债就好比修改和扩展软件系统，每当添加新功能时，需要付出的额外努力就好像是债务利息一样。那么身为技术开发者，该如何偿还技术负债？
以下为译文：
软件系统常常建立在内部质量有缺陷的代码之上，因此比理想情况下更难修改和扩展系统。技术负债是Ward Cunningham提出的一个比喻，形容这个问题就像金融债务一样，添加新功能时，需要付出的额外努力就好像债务利息。
假设我的代码库中有一个混乱的模块结构。此时，我需要添加一个新功能。如果这个模块结构清晰，那么我只需要4天时间就可以添加好这个功能，但是如今这个模块的结构很混乱，所以我需要6天时间。多出来的这两天就是债务利息。
关于债务的这个比喻最吸引我的地方在于，它让我思考如何处理这个问题。假设我可能需要5天时间来清理这个模块化的结构，改好不健全的功能，这就相当于支付本金。如果只有这个功能需要用到这个模块，那么就得不偿失，因为我总共需要9天时间，如果我继续容忍这个模块的话只需要6天。然而，如果有两个相似的功能都用到了这个模块，那么我肯定会首先改好这个模块来加快速度。
如此说来，听起来这是个简单的数字问题，凡是有电子表格的经理都应该能够做出很好的选择。遗憾的是，我们并不能很好地衡量我们的生产力，因此这些成本都无法客观地衡量。我们可以估算完成一个功能需要多长时间，我们需要估算做新功能的时间（在改好模块后的情况下），以及改好这个模块的时间。然而，我们的估算的准确性非常低。
鉴于此，通常我们的做法是：背负着负债继续做新功能，并逐步支付本金。在做第一个功能的时候，我会花额外的几天时间来修复一些不健全的功能。这可以将未来的利息降低到一天。虽然这之后我们仍然需要花费额外的时间，但是这些代码附带的负债会降低。这种逐步改进的好处在于，如果我们频繁地改动某个有待修改的负债，那么就证明这些代码正是最需要被清理的区域。
这种用支付利息代替支付本金的方式，可以帮助我们决定优先解决哪个负债。假设有一个非常可怕的代码库，修改这个代码库简直就是一个噩梦，如果我没有必要动这个代码库，那就不是个问题。只有当我用到这部分软件时，才需要支付利息（这是这个比喻与金融上的负债不同的地方，因为金融的利息支付是由时间决定的）。因此，我们可以不必理会那些稳定的负债。相比之下，活跃度非常高的区域需要非常及时地修改，我们应该采取零容忍的态度，因为这部分债务的利息非常高。这一点非常重要，因为开发人员往往只知道一味地更改代码，却不关注内部质量的时候，这些负债将不可避免地积累起来——代码变更越多，风险就越大。
有时，这种债务的比喻也可以判断是否应该忽略内部质量。关键在于我们需要付出时间和精力才能阻止负债的积累。如果有些新功能非常迫切，那么也许我们不得不继续背负债务，只有等到将来再来处理这笔负债。
然而，大多数时候我们的这种分析做得都不好。另一方面，技术负债的影响非常快，会迅速拖慢新功能开发的速度。不断积累负债的团队最终都会被自己的债务搞得一塌糊涂，大幅延迟交付，所以还不如趁早努力提高内部的质量。这个比喻往往会让人误解，因为这种发展趋势与金融贷款并不完全相同。
人们经常会争论是否应该将不同种类的质量问题视为债务。我觉得我们应该考虑这些债务是有意造成的，还是一时不小心造成的。
（文章来源：CSDN 翻译）
责任编辑：
