关于何时偿还技术债务的建议

Spotify 的敏捷教练 Henrik Knibert 最近写了一篇文章，论述了为什么有一些技术债务可以成为一件好事以及可以将其作为判断系统质量的依据。

Henrik 写到，应该避免并有计划地偿还“旧债务”。他还写到，在得出一套“简洁优雅的解决方案”之前，一段时间的试验性尝试和探究是改正一项功能以及理解解决方案的一部分。这种债务应该立即偿还。旧债务会使软件栈衰败并导致交付速度越来越慢。他把这一点与一些日常类比进行了比较：

如果一个人打开电脑开始做新的事情，却发现昨天做事时打开的许多窗口和文档仍然打开着，那会降低做事效率。就像如果一个人去厨房做晚饭却发现里面满是昨天用过的盘子和剩饭剩菜。

Hayim Makabee 是 Yahoo! 的研发工程师和以色列国际软件架构师协会的联合创始人。最近，他写了一篇题为“避免技术债务：如何逐步增加技术储备（Techical Savings）”的博文，探讨了技术储备的问题，认为良好的并且适应性强的设计可以预先偿付债务。他写到“重构干扰（Refactoring Distractor）”，认为在那种情况下有太多的时间花在了后来的重构上。Hayim 提倡“预先适应性设计（Adaptable Design Upfront，缩写为ADUF）”范式，通过这种方式，他认为可以使用 SOLID 原则围绕对高层次概念的初步了解创建基于组件的设计。这样，可以在具体实现和组件交互时处理理解上的变化。ADUF 与 XP 创始人 Martin Fowler 关于用演进式设计代替“预先做大量设计（Big Up Front Design）”的主张有一些相似之处。他先前写到“设计人员需要学习如何做一个简单的设计，如何使用重构保证设计的简洁，以及如何在演进式方式中使用模式。”

在写到 ADUF 时，Hayim 阐述了该方式的一个切实可行的实现：

框架中的每个组件都应该设计成高内聚的，而且框架本身的设计应该使各组件之间是弱耦合的。如果组件接口真是抽象的，并且如果这些组件之间真是弱耦合的，那么框架中的每一类组件都可以看作一种插件。

术语“技术债务”的发明人 Ward Cunningham 在今年早些时候接受了网站 OnTechnicalDebt.com 的采访。在探讨提前偿还技术债务时，Ward 认为，如果不想“冒没钱花或者交付一半功能点代码的风险”，那是一个选项。他还指出，在现代持续交付的世界里，缺陷和不良设计都有其可接受的水平：

……当然，有许多方法可以用来构建能够工作的软件，其中一个甚至使我现在都惊讶的观点是，那些运营大型网站并尽可能快地捕获登录信息的人常说，他们给予质量的关注比他们认为需要给予的更少，而他们给予弹性的关注则更多——也就是即使出现错误仍能继续推进的能力。

Henrik 认为，软件永远不会完美，编写无债务代码的机会成本可以从交付次数中看出来。

从理论上讲，把每个功能的技术债务降为零会非常棒。而实际上，这还涉及 80/20 规则。将技术债务保持在一个低水平上所需的工作量还比较合理，但消除剩下的一点点技术债务所需的工作量却高的离谱。

他建议引入债务上限来处理由于过程缺陷而生成的债务。虽然大部分新债务可以实时地偿还，但当达到债务上限的时候，所有的资源都应该致力于降低债务水平：

债务上限应该设置的足够高，那样就始终都不会达到上限，还应该足够低，那样达到上限的时候也不会遭受无法挽回的损失。

虽然可能永远无法达到零债务的状态，但 Hayim 的 ADUF 模式提供了一种可以用来做这种预先储备的方法。Henrik 和 Ward 提醒我们，接纳技术债务是为了在可接受的时间范围内交付可用的产品有意做出地一种让步。Hendrik 在文章末尾指出，债务积累的越多，就越会阻碍未来开发和团队精神的发展。Henrik 已经向我们证明，通过监控技术债务可以更好地了解风险点和平台健康状况。控制技术债务水平并有计划地偿还债务是我们之后必须积极地予以优先考虑的。

Henrik 写道：

一个简洁的代码库不仅能使工作效率更高，而且它更有趣（或者不那么让人厌烦，如果读者更喜欢以这样的方式看事情……）。它还会激励开发人员，有助于他们更快地创建更好的产品，这反过来又会使客户和开发人员都更愉快。一个很好的良性循环。

查看英文原文：**** Advice on When to Repay Technical Debt