初探“技术债务”

最近举行了一个技术债务研讨会，以改进我们对“技术债务（technical debt）”的理解及其解决之道，该研讨会迸发出一些有趣的观点。其中一个观点引起了包括 Michael Feathers 和 Brian Marick 在内的很多人的注意，那就是我们应该将对问题的理解集中在“资产”而不是“债务”上。

会议组织者 Matt Heusser 和 Steve Poling 介绍了他们对这个持续两天的会议的愿景：

成功的会议应能采取一些具体的度量，通过这些度量来对技术债务进行切实可行的讨论。当我们说自找麻烦就像借钱一样时，我们并没有自欺欺人，这一点会议已经给我们提供了证据。（往好点说，我们证明了另一个动态是在开玩笑。）该会议还将阐述债务管理和债务偿还策略以及它们何时会显现出来。

该会议意在解决如下三个主要问题：

1. 什么是技术债务？什么不是？
2. 我们如何对其进行度量？其影响如何？
3. 我们能否像管理其他债务一样去管理技术债务？

该会议迸发出一些有趣的观点，Heusser 总结如下：

• 无知：劣质代码要么产生于无知，要么产生于错误的决定。请阅读Brian Marick 的文章以深入了解这一点。
• Bug 修复：发现 Bug 后一定要尽早修复；由此产生了stop-the-line文化。
• 风险：客户没有对团队施加足够的影响会导致开发速度很快但是质量很低，这是由Heusse 引入的观点。
• 不匹配：如果开发者的技术水平参差不齐，那么就会对代码质量产生副作用，这使得开发任务很难完成。请阅读Chris McMahon 的文章以深入了解这一点。
• 流动的资产：或许“技术债务”让我们专注于错误的事情上；或许专注于相反的事情、专注于投资（McMahon 最近谈到了这一点）更有效。
• 供给：证明团队在正常的情况下可以降低技术债务，这样就可以“增加资产”了。

或许上面这些观点中最有趣，大家也最熟悉的就是从另一个角度思考技术债务：努力“增加资产”。从会计学的“借贷”角度来说：一个人可以将精力集中于减少借款或者增加存款，但最终理想的目标还是增加资产。某些情况下这只是视角的问题。

就在会议之前 Michael Feathers 提出了“代码即资产”这样一种观点。他的观点很大程度上表明从“资产”角度看待代码会接近人类的本性，这会对代码质量及“技术债务”问题的反映产生更好的结果。根据 Feathers 所述，这样做更好，因为人们都喜欢获取东西（“资产”）而不是损失东西（“债务”）。

随后 Brian Marick 继续该讨论，他使用了“充裕的资产”来描述代码质量对开发所产生的结果。他将其类比于园艺，说到土壤必须保持肥沃以持续种植，但尽管如此也不能永远肥沃，这样就有碍于种植了。他的想法就是产品代码与此类似。

此外 Brian Marick 还撰写了一篇简短但有趣的捧场文章，重点讲述了一些著名的敏捷文化的鼓吹者对降低债务的团队有什么特别之处这个话题的描述。

与往常一样，请点击下面的链接以了解全部内容的总结，然后回来谈谈你对这些观点的看法以及经历。

查看英文原文：A Fresh Look at 'Technical Debt'