管理软件债务

软件债务以不同的形式存在。技术债务广为人知，能力债务和质量债务是另外的一些形式。软件债务会导致产品运维成本增加，使开发人员沮丧。现在有几种解决方案可以管理软件债务。

在博文《另一种软件债务》中，Niklas Björnerstedt 谈了“能力债务”，并将它定义为：

代码库中有什么和你了解多少之间的差距。

为了将软件运维成本保持在一个较低的水平上，技术债务和能力债务都应该受到重视，正如 Niklas 的阐述：

除非你偿还，否者技术债务将不可避免地随着时间增长，同样地，能力债务也会随着时间增长。这两种债务之间最大的不同在于：代码库修改越多，技术债务增长越快；而如果停止修改，能力债务就会更快地增长。因此，在成熟的系统中，现行开发已经结束，能力债务最为严重。

Niklas 推荐了两种可用于减少债务的技术：结对编程和代码重构：

在我看来，结对编程的真正价值在于减少了技术债务和能力债务。通过结对，团队成员扩大了他们熟悉的代码库范围，并且增加了重叠范围。类似地，重构的价值也不仅仅是减少技术债务。重构还是一种减少能力债务的好方法。只有真正地了解一个系统时，你才能修改它。

当能力债务增长，系统运维所需的工作量就会增加，到了一定程度，组织就会开始考虑替换该系统：

当真正的问题是他们不知道系统如何工作时，人们就会声称旧系统无法运维。是的，技术债务使情况变得更糟，因为混乱的代码和缺少自动化测试使得系统了解起来令人沮丧。当最初的开发人员剩下的太少，而企业又无法找到新的能够或愿意学习的开发人员，通常就会产生重写的冲动。

Mike Hustler 写了一篇博文《管理技术债务最敏捷的方式》。他在文中探讨了如何平衡产品开发能力和管理技术债务。他对将产品移交给运维团队如何导致技术和能力债务的增长进行了说明：

我见过有的组织建立一个单独的运维团队，比如，规模是新功能团队的一半。在我看来，这个做法是错误的（至少，对于与我们合作的那种规模的团队而言是如此）。（……）源于主人翁自豪感的那份坚持没有了，因为某人正在处理的 Bug 是由另一个人造成的，事实上，是另一个团队。如果没有良好的沟通，最初为什么采用某个特定方法的背景就无从知晓。缺少领域知识导致问题修复的效率降低。更糟糕的是，我见过有的运维团队，成员是缺乏经验的开发人员，他们很难确定问题的根源，导致了将返工当首选的创可贴式修复的发生。

技术债务会令开发人员沮丧，并使他们放弃会增加能力债务的系统。Cory House 在博文《干净代码重要的七个原因》中有这样的描述：

编写马虎或混乱的代码会使项目出现技术债务。当结合上下文仔细考虑，技术债务可能有用，但过多的技术债务会令人沮丧，进而导致组织人才流失。当简单的事情变得困难，开发人员开始用脚投票，去其它地方。相比于工作数量，开发人员更能从其工作质量上获得工作满足感。技术债务降低了重用机会，而且为代码库的其余部分设置了一个较低的质量门槛。

David Hammerslag 写了一篇博文《想要可预见性吗？避免质量债务》。在文中，他探讨了放着代码中已发现的缺陷不解决的影响。他将质量债务定义为：

质量债务是在任意给定的时间点修复软件产品中的一个缺陷所需要的工作量的度量。

他将质量债务与技术债务做了比较：

技术债务衡量设计和代码的质量，是软件的内部质量。质量债务衡量代码的外部质量，是用户可以看到和体验到的东西。用户永远无法（直接）看到技术债务。

一个程序可以完全没有质量债务，而有大量的技术债务。所有必需和预期的功能都可以正确地实现，并完美地运行。然而，技术债务可能相当多，显示出你能想象到的每一个糟糕的软件设计和实现。另一方面，最好的设计，最优雅的代码也可能产生错误的结果或缺少功能。

David 写道，质量债务应该忽略：

质量债务很像财务债务：时间越久越难偿还。在最坏的情况下，项目将测试推迟到开发完成之后。缺陷存在时间越久就越难以修复，这已是不争的事实。如果许多缺陷持续存在（不管是已知的，还是未知的），影响就会因为缺陷相互遮掩而加剧，而修复会涉及相同的代码。

David 推荐了几种可以用于管理缺陷及将质量债务保持在较低水平上的敏捷实践：

• 完工定义。
• BDD/ 自动验收测试。
• 持续集成。
• 自动化测试。
• 不容忍“破窗”。

查看英文原文：**** Managing your Software Debt