初探“技术债务”

最近举行了一个 技术债务研讨会，以改进我们对“ 技术债务（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'