TechnicalDebt

2019年5月21日

软件系统容易建立繁琐的东西- 内部质量的缺陷使得它比理想情况下更难以更加修改和扩展系统。技术债务是一个隐喻,由Ward Cunningham创造,框架如何考虑与这种Cruft进行处理,想到它就像金融债务一样。增加新功能需要的额外努力是对债务所支付的利息。

假设我的代码库中有一个令人困惑的模块结构。我需要增加一个新功能。如果模块结构很清楚,那么我就需要花4天时间去添加功能,但是对于这个小玩意,我只需要6天。这两天的差额是债务的利息。

对我来说有什么吸引力的债务隐喻是如何框架我如何考虑如何处理这个cruft。我可能需要五天时间来清理模块化结构,从而消除CRUFT,偿还校长。如果我只为这个功能做到这一点,那就没有收获,因为我需要九天而不是六个。但是如果我有两个更类似的特征即将到来,那么首先删除Cruft将最终最终最终。

是高质量的软件是否值得花费?

在软件开发项目中,一个常见的争论是在花188比分直播完整手机版时间改进软件质量和集中精力发布更有价值的特性之间。通常交付功能的压力主导了讨论,导致许多开发人员抱怨他们没有时间来处理架构和代码质量。188比分直播网 坚持原创这场辩论基于这样一个假设:提高质量也会增加成本,这是我们的共同经验。但与直觉相反的事实是,内部软件质量消除了减慢新功能开发的困难,从而降低了增强软件的成本。

这样说,这听起来像是处理数字的一个简单问题,任何有电子表格的经理都应该找出选择。遗憾的是由于我们CannotMeasureProductivity,这些成本没有一个是可以客观衡量的。我们可以估计做一个功能需要多长时间,估计如果把皮屑拿掉会是什么样子估计除去皮屑的费用。但我们对这些估计的准确性相当低。

考虑到这一点,通常最好的方法是像我们通常对待金融债务那样,逐步偿还本金。对于第一个特性,我将花费额外的几天时间来移除一些污垢。这可能足以将未来提高的利率降低到一天。这仍然需要花费额外的时间,但是通过删除这些繁琐的东西,我可以使将来对这段代码的更改更加便宜。像这样逐步改进的最大好处是,它自然意味着我们要花更多的时间在频繁修改的区域中删除cruft,而这些区域正是代码库中我们最需要删除cruft的区域。

考虑到这一点作为支付利益与校长的支付可以帮助决定哪个cruft解决。如果我有一个可怕的代码基础区域,那么一个是一个噩梦改变,如果我不必修改它,这不是一个问题。当我必须使用该一部分软件时才触发利息付款(这是一个隐喻崩溃的地方,因为金融利息支付是通过时间的推移触发)。所以Crufty但稳定的代码区域可以单独留下。相比之下,高活动领域需要对Cruft的零容忍态度,因为利息支付越来越高。这尤为重要,因为Cruft积累了开发人员在不关注内部质量的情况下做出变化的情况下 - 越改的变化越大,Cruft建设的风险越大。

债务的比喻有时被用来证明忽视内部质量是正确的。他们的观点是,阻止垃圾堆积需要时间和精力。如果有迫切需要的新功能,那么也许最好承担债务,接受债务必须在未来进行管理。

这里的危险在于,在大多数情况下,这种分析都做得不好。Cruft有一个快速的影响,减慢了非常需要的新特性。这样做的团队最终耗尽了他们所有的信用卡,但仍然比他们将精力投入到更高的内部质量上要晚。在这里,这个比喻常常会让人们误入歧途,因为它的动态与金融贷款并不匹配。只有在你的设计回报线以下的情况下,承担债务来加速交付才有效DesignStaminaHypothesis团队在几周内就达到了这一目标,而不是几个月。

对于不同种类的杂物是否应该被视为债务,经常存在争论。我发现思考一下债务是故意的还是谨慎的还是鲁莽的是很有用的TechnicalDebtQuadrant

进一步的阅读

据我所知,Ward首先在一份经验报告中介绍了这个概念oopsla 1992..它也已经讨论过维基

沃德·坎宁安有视频说话他讨论了他创造的这种隐喻。

Dave Nicolette详述了Ward对技术债务的看法细的案例研究我指的是谨慎的有意的债务

一些读者送来了一些类似的好名字。David Panariti将丑陋的编程称为赤字编程.显然,他最初是在几年前开始使用这个词的,因为这符合政府的政策;我想现在又很自然了。

斯科特·伍德建议"技术的通货膨胀当当前的技术水平超过了你的产品的基础水平,以致于它开始失去与行业的兼容性时,可以被视为失去了根基。例如,当你的代码在语言版本上落后于主流编译器时,你的代码将不再兼容主流编译器。”

Steve McConnell在隐喻中提​​出了几个好点,特别是如何保持你的意外债务,让您在有用的时候有意承担债务的空间。我也喜欢他对最低付款的概念(非常高,以解决嵌入式系统而不是网站的问题)。

Aaron Erickson说的安然公司融资

Henrik诺贝格辩称旧的技术债务才是最大的问题,明智的做法是设定一个质量债务上限来帮助管理它。

埃里克·迪特里希讨论技术债务的人力成本:团队无法解决,萎缩技能和磨损。

修正

我最初在2003年10月1日发表了这篇文章。我在2019年4月彻底重写了它。