放开技术债务

沃德•坎宁安（Ward Cunningham）首次引入“ 技术债务 ”一词作为隐喻。 到了90年代初，开发人员和商人之间的分歧越来越大。 商界人士会敦促开发人员发布未经测试的丑陋代码。 开发人员试图解释为什么这是一个严重的错误。 （不像今天，对吧？）

代码和设计中债务的隐喻是这样的：我们从最佳代码级别开始。 在下一个版本中，我们将添加一个新功能。 这将需要E的努力（假设估计是可行的。请在此处与我合作）。

如果我们的代码级别低于最优，努力将是E + T。其中，T是技术的债务。 编写错误的代码就像陷入债务。 我们现在借贷，稍后再偿还债务。 混乱越大，下一个版本的延迟就越大。

这是一个很好的隐喻。 就像一切都很好一样，我们也设法做到了。

大多数项目的发布时间仍比开发人员想要的要早得多。 假设开发人员不仅固执己见（再次与我合作），您可能会认为这个比喻使我们失败了。 我们没有设法将信息传达给企业。

互惠生！

我们做了出色的解释。 商界人士明白这一点。 他们只是愿意现在就借钱。

你能怪他们吗？ 首先，他们要在野外买一些现在可以卖的东西。 根据他们在开发人员中的经验，业务人员不知道什么时候发布，甚至不会发布下一个版本。 在我们这个复杂的世界中，我们不知道下一个版本会及时发生什么。 也许现在处理代码将使下一个版本的工作变得更加容易，但是下一个版本可能在不同的代码上包含完全不同的功能。

让我们假设在发布之前有一个讨论。 这是关于延迟发布并改进代码或现在发布。 我的钱是决定以较差的质量为代价提前发布。 该公司宁愿现在拥有一些东西，并且该死鱼雷。

不仅如此。

复杂性非常残酷。 事后看来很难评估实际的技术债务。 因此，您可以对老板说：“您上次做出的决定使我们多花了3周的时间”，但这个数字将完全弥补。 我们真的不知道仅仅因为代码不够好而实际花费了多少。 如果是这样，但是一个全新的团队正在研究它之前不知道该怎么办？

如果事后分析不起作用，您可能会猜测当前技术债务的估计还款问题甚至更大。 不幸的是，这并不能阻止人们尝试。

例如，在SonarQube中，有一个模块可以让您计算技术债务 。 它考虑了代码重复，覆盖率和复杂性指标以及各种数字，将它们全部放入碗中，并提供了一个数字，您可以在决策时向老板显示此数字。 多么酷啊？

好的，首先要考虑的事情：不要向老板展示。 她不会被黑色魔法配方炮制的虚构数字打动。 此外，如果您有预言未来的东西，可以用它成为自己的老板。

当我第一次看到此消息时，向所有人显示了技术债务编号（以工时为单位）（是为了提高可见度！）。 大多数人都忽略了它，因为数量如此之多，因此想出如何缩小差距的计划（好像是准确的）实际上是不可能的。

我们再次使用工具来避免不确定性，并创建一个简单的海市rage楼。 有些人甚至会相信。 并据此做出决策。 与任何估计一样，如果您没有数据，那么它们也就不值钱了。 不，您不能将代码重复转换为工时，除非您的开发人员是盲目的打字员。

技术债务是一个很好的比喻，可以解释，但是它既没有达到我们想要达到的目标，也没有在可靠性上留下任何痕迹。

是时候放手了。

翻译自: https://www.javacodegeeks.com/2015/10/letting-go-of-technical-debt.html