技术债还是有用的隐喻吗？

技术债由 Ward Cunningham 提出，是指：

另一个更严重的缺陷是无法稳固 。虽然不成熟的代码有可能工作正常也能被客户完全接受，额外的工程量将会导致程序不可掌控，引发程序的极端特化并最终得到一个不灵活的产品。交付第一次的代码就像开始背负债务。少量的债务可以加速开发过程，但很快就要偿还回来，代码需要重写。目标让这种成本可被接受。当债务没被偿还的时候会引发危险。在“不那么正确”的代码上花费的每一分钟都是技术债的利息。整个工程组织都会因这种债务压力导致的不稳定的实现，无论是面向对象还是其它方法，而停滞不前。

在 LinkedIn 敏捷联盟小组的一个讨论中质疑“技术债”在如今全球化软件开发世界中是否仍是个有效的隐喻。 Marvin Toll 发起了这个讨论，他说到：

在将近二十年之后可能我们现在有足够的经验来观察这个隐喻是否还有效。我的观察？“没什么用”在一个愈加全球化的 IT 社区中，英语作为第二语言，140 个字符就能引起注意，这个隐喻的细微差别已不能很好的指导应用程序开发了。

换句话说，关于劣质代码的讨论陷入解释财务用例的困境。

绝大多数人站出来为这个术语辩护，它的重要性在于让人们关注一个常常忽视但代价高昂的问题。 Daniel Nelson 分享了他的感受，即人们不熟悉这个术语的危险：

从我数年的编程经历、然后成为业务分析师、现在是 CSPO 的经验来看，我发现如果敏捷团队成员没有对技术债（无论在你的特定环境下叫做什么）哪怕基本的理解将是危险的，也是引发和补救这种技术债的常见原因。

没有明确的实践来预防它，技术债能够并会发展超出控制并损害软件。代码会变得缺陷众多、零碎，并导致接口混乱。

我喜欢这里用的隐喻并认为适用得很好，只要用某些东西提醒团队注意这些问题。

Steve Gordon 指出隐喻可以并存：

隐喻只是模型，但使用其它常见的概念而非数学术语或绘图约定。像所有模型一样，隐喻描述了某个方面并忽视了其它方面。

技术债隐喻描述了劣质代码的持续增长的成本。它并不想描述坏的代码是什么……许多模型或隐喻能没冲突的共存，特别是当它们描述不同的方面或让不同的人达成共识。

Curtis Stuehrenberg ，QA 经理，解释了为什么对他的角色来说技术债是个重要的术语：

我个人喜欢这个术语，因为关于它的讨论趋向凸显主题和冲突，这在通常的标准项目团队中是想掩盖的。无论你在那种团队中，总会有你了解需要做的基础设施的事情和销售团队知道他们能卖更多钱的炫目的功能的角力。如果你关注居住改善，你也会看到类似的角力，卖房者尝试在卖出房子之前粉饰一新。房屋代售的每一天，卖房者都会损失钱，无论是直接的维持成本还是他可以将资本投资其它方面的间接成本。这就导致了售房者希望项目时间尽可能短。他们也希望尽可能少的投资以便最大化他的投资回报率（ROI）。

如果你仔细观察，你会发现有经验的售房者尽其所能的避免做诸如打开墙壁或挖开地板之类的事情。有经验的售房者知道一旦他们做了这些事，他们从统计上来说总会发现他们不得不因结构或安全原因进行修复或是基于法律缘故告知潜在买家的有风险的事实。

项目中的技术债就像隐藏在墙后的，埋于地板下的和在屋顶內的缺陷。大多数团队会花大量精力不搞坏原始的源代码因为他们知道一旦这么做了他们就是打开了需要高昂代价重做的大口子。就像房屋一样，代码库越老你越可能发现把手和管子的线路或石棉或铅涂料。

这就是为什么我作为一个 QA 喜欢谈论“技术债”。如果我们只是等在那儿并说我们隐约担心检查天窗因为我们非常肯定会找到黑霉菌，那我们可以理性的评估风险并选择一个风险规避策略。不谈论它只意味着一些人正在试穿一件新的公司衬衣后背缝着巨大的靶子。

因此，技术债是一个好的隐喻吗？看上去对于大多数人还是管用的，至少它没什么害处。它可能不适合所有的文化和所有团队，这也可以接受因为隐喻可以共存。这符合你的经验吗？

查看英文原文： Is Technical Debt Still a Useful Metaphor?