技术债务象限

在过去几个月里，关于技术债务的帖子引发了关于哪些设计缺陷应该或不应该被归类为技术债务的问题。

一个很好的例子是鲍勃叔叔的帖子，他说混乱不是债务。他的论点是，由不了解良好设计实践的人员产生的混乱代码不应该被视为债务。技术债务应该保留给那些人们经过深思熟虑后决定采用一种在长期内不可持续但能带来短期利益的设计策略的情况，例如发布版本。关键在于，债务可以更快地带来价值，但需要尽快偿还。

在我看来，一个设计缺陷是否构成债务这个问题本身就错了。技术债务是一个比喻，所以真正的问题是债务比喻是否有助于思考如何处理设计问题以及如何传达这种思考。债务比喻的一个特别好处是，它非常方便与非技术人员沟通。

我认为债务比喻在这两种情况下都适用 - 区别在于债务的性质。混乱是一种鲁莽的债务，会导致沉重的利息支付或长时间偿还本金。我们有一些项目接手了代码库，这些代码库存在大量债务，发现这个比喻在与客户管理层讨论如何处理这些债务时非常有用。

债务比喻提醒我们，在处理设计缺陷时可以做出哪些选择。为了发布版本而产生的谨慎债务可能不值得偿还，如果利息支付足够小 - 例如，如果它位于代码库中很少触碰的部分。

所以，有用的区分不是债务与非债务，而是谨慎债务与鲁莽债务。

我刚才提到的例子中还有一个有趣的区别。不仅存在谨慎债务与鲁莽债务之间的差异，还存在故意债务与无意债务之间的差异。谨慎债务的例子是故意的，因为团队知道他们正在承担债务，因此会考虑提前发布的回报是否大于偿还债务的成本。一个不了解设计实践的团队会在不知不觉中承担鲁莽的债务，甚至不知道自己陷入了多么糟糕的境地。

鲁莽的债务可能并非无意的。一个团队可能了解良好的设计实践，甚至能够实践它们，但他们选择“快速而肮脏”的方式，因为他们认为他们没有时间编写干净的代码。我同意鲍勃叔叔的观点，这通常是一种鲁莽的债务，因为人们低估了设计回报线的位置。良好设计和干净代码的全部意义在于让你更快地完成工作 - 如果不是这样，像鲍勃叔叔、肯特·贝克和沃德·坎宁安这样的人就不会花时间谈论它。

将债务划分为鲁莽/谨慎和故意/无意意味着一个象限，而我只讨论了三个单元格。那么，是否存在谨慎-无意债务？虽然这种说法听起来很奇怪，但我相信它确实存在 - 而且它不仅很常见，而且对于那些优秀的设计师团队来说是不可避免的。

我最近和一位同事聊天，他刚从一个项目中退出。这个项目交付了有价值的软件，客户很满意，代码也很干净。但他对代码并不满意。他觉得团队做得很好，但现在他们意识到设计应该是什么样子。

我经常从最优秀的开发人员那里听到这种说法。关键在于，在编程过程中，你一直在学习。通常情况下，可能需要一年的项目编程才能理解最佳设计方法应该是什么。也许应该计划项目，花一年时间构建一个你抛弃并重建的系统，就像弗雷德·布鲁克斯建议的那样，但这很难让人接受。相反，你会发现，当你意识到设计应该是什么样子时，你也会意识到你有一个无意的债务。这就是沃德在他的视频中谈到的债务。

支付利息与偿还本金的决定仍然适用，因此这个比喻在这种情况下仍然有用。然而，在这个比喻中使用债务比喻的一个问题是，我无法想象与承担谨慎-无意财务债务相似的行为。因此，我认为很难向管理人员解释这种债务是如何出现的。我的观点是，这种债务是不可避免的，因此应该预料到。即使是最优秀的团队也会在项目进行过程中遇到需要处理的债务 - 更有理由不要鲁莽地用糟糕的代码过度负荷它。

2014年11月19日重新发布