技术债务：为什么它会毁了你的软件

如你所见，这是意大利的一座著名的纪念碑，更确切地说是在比萨，因此它的名字是：比萨之塔。

这座塔有一段非常有趣的历史，它建于12世纪左右，但由于地基松软，它开始倾斜。经过8年的修补工作，该结构直到2001年才稳定下来。

事实上，在这8年中所做的一项修正让倾斜变得更糟！让那些从未做过使问题变得更糟的重构的人来扔第一块石头吧。我真的不能责怪任何人，哈哈。

由于约翰是一名优秀的专业人士，总是能完成他的活动，所以他迎头赶上了新项目，并及时交付了它。

在John交付之后，他的团队其他成员继续检查他的代码，他们发现了一些问题，例如：

约翰知道他的代码有几个错误。但是临近最后期限，另一个项目出现了，约翰花了很多时间，所以他不能回去解决问题。

因为发生的事情是John在这么短的期限内选择了他能想到的第一个解决方案，这影响了代码的质量，团队接受了这一点。在未来，如果企业的任何物流需要改变，例如接受不同种类的货币或改变送货服务，代码的改变成本将是巨大的。John为他选择最快、最简单的解决方案的那一刻就是将技术债务插入到代码中的那一刻。

比萨塔发生的事情很像我们所理解的技术债务。

一开始可能只有几个小错误和问题，但构建者决定忽略它们，并在这些问题上进行构建和扩展。这座塔建造得如此之快，以至于施工中的这些小“虫子”危及了整个结构。

同样的事情也可能发生在软件上。不同的是，在开发过程中更容易发现错误和问题，因为过了一段时间，在嗯修复这些错误之前，新功能就不可能交付了。

我们习惯于将软件中的任何技术债务理解为非常糟糕的事情。通常都是这样。

但我们也可以将其视为一个战略和/或经济决策，因为一个充满技术债务的项目仍然是一个交付速度很快的项目。这对产品来说可能是一件非常积极的事情。

当我们开始忘记过去的所作所为时，这种方法的问题就开始了。想象一下，技术债务是一种真正油腻可口的垃圾食品。吃一两次可能很棒，但在吃完第八顿欧式第九餐之后，可能是时候承认你有问题了。

通过接受这是一种权衡，我们可以更快地在未来偿还债务。这真的是一件非常正常的事情。

我不知道你们中有多少人为太多的垃圾食品付出了代价。只需记住，这一成本以及软件成本都会随着时间的推移而变得更高。

如果您在日常任务中发现了其中一些情况，请不要担心，特别是如果您将来有时间来解决问题的话。在处理软件交付时，这是一个非常常见的场景。

如果我们看看马丁·福勒(Martin Fowler)的技术债务象限，我们可以看到约翰处于上象限，介于鲁莽和谨慎之间。

他知道他没有足够的时间来设计最好的解决方案，但他也知道：在未来，他必须回来改进他的代码。

好的，接受这件普通的事情，我们可以试着理解到底是谁对软件的债务负责。

如果我们把重点放在名称(技术债务)上，我们会认为这是技术人员造成的问题，即：开发人员，他们负责编写最终导致债务的代码。

问题是，软件是整个公司结构和流程的结果。

而且，自从“技术债务”这个术语诞生以来，整个软件行业都发生了变化。例如，在John的场景中，他精心设计的不太好的解决方案的问题更多地与管理问题有关，甚至与产品团队有关，而不是与他自己有关。我们知道John是一个优秀的开发人员，但是为了在规定的期限内交付，他不得不忽略很多问题。

有时，造成债务的瓶颈来自公司的不同部门，例如：

但我们不能忘记，有时候，我们确实要为自己的错误决定负责。

例如，当我们选择一个新的令人兴奋的框架时，没有投入必要的时间来了解这是否是手头工作的最佳工具，或者甚至当我们不再关注框架正在被抛弃的迹象时，或者当开发人员没有按照他们应该…的方式测试和重构应用程序时。这一切都是我们的错。

在发现我们的代码中存在哪些问题之后，我们需要寻找可以用来帮助我们处理这种情况的工具。

想象一下，如果人们干脆停止建造比萨塔，并摧毁一切进行重建。同样的错误，甚至是新的错误，发生的可能性真的很高。并考虑一下拆除和重建所有东西所需的资金数量。

如果公司只是雇佣更多的人来解决债务问题呢？在铁塔的例子中，我们会有试图把它建得更高的人，与试图让它笔直而稳定的人一起工作。这确实没有解决主要问题。

在软件方面，雇佣一个新团队来处理现有问题意味着旧团队将不得不花时间向新团队解释软件的整个上下文。相信我，这比你想象的要花更多的时间。

如果我们创建一个新的位置来存储我们的技术债务任务，会怎么样？过了一段时间，这个地方对团队来说就完全看不见了。

如果一个普通开发人员的待办事项已经有了自己的老任务和看不见的任务，想象一下用不同的任务创建一个完全不同的板。然而，这些都是大多数人通常寻找的解决方案。

那么，栾安，如果这些选择不是最可行的，我们能做什么呢？

在我们已经知道的情况下，我们必须设法找到真正可行的解决方案来处理技术债务。

正如我们看到的，第一步是找到债务点，第二步，我们需要确保这些点对整个团队都是显而易见的。例如，您可以通过创建标记为技术债务的新任务来确保这一点。我们还可以根据这些任务的相关性来选择它们的优先级。像Jira这样的工具有随时间增加某些任务优先级的机制，这很令人惊讶，因为正如我们以前看到的那样，技术债务的成本会随着时间的推移而增加。

在此之后，我们需要为标记的任务创建一个计划，并真正遵循该计划。这样，我们将有效地对债务采取行动，在修复和改进实施后，我们需要测试并确保没有任何行为受到损害，无论是新的错误、功能、改进，还是任何可能阻碍最终体验的行为。

您可以在一本名为“面向软件设计嗅觉的重构-管理技术债务”的书中找到关于这一点的更多详细信息。

如果您不知道每个团队迭代应该有多少任务。

我们可以使用Pareto原则将团队生产力的20%分配给技术债务任务，剩下的80%用于普通任务，作为新功能、错误修复和其他一切。

如果在几次迭代之后您的流程中有大量交付，那么让事后团聚来讨论引入到代码中的所有有可能增加技术债务的东西可能是一件好事。

这是可能的解决方案的三个示例，但我建议您格外挑剔，选择最适合您和您的团队的解决方案。

让我们来探讨一下这个问题的经济方面。使用一个已经有很大技术债务成本的系统是否有利可图？

我将用J.B.Rainsberger的一次演讲来说明我的观点。在本讲座中，Rainsberger解释了软件的下一个新功能的成本，以及如何在估算此成本时降低错误率。

正如我们所看到的，没有考虑设计、重构和良好实践而构建的软件的成本比通过设计思考开始项目的成本要高得多。

尽管通过考虑架构设计来启动项目的初始成本较高，但我们也可以注意到，与没有这些问题的方法相比，在项目的整个生命周期中，这一成本都会降低。

如果没有设计，软件中新功能的成本将变得如此之高，以至于停止一切并重建整个系统在财务上是一个好主意。

如果您当前以这种方式编写软件，那么您实际上是在打赌项目将在虚线之前结束。

关于这些估计，最困难的部分是我们永远不知道虚线什么时候会到来。可能是3个月、1年、10年…。我们根本不知道。

2018年，CISQ发布了一份关于美国软件成本的报告，计算时考虑了：遗留系统、灾难性故障、问题和取消的项目成本。相比之下，他们抵达的费用相当于同年美国所有医疗费用的三分之二。

程序员平均每天花费3.8小时调试糟糕或低质量的代码。那么，想象一下所有的钱都用在了其他方面，比如更高的工资、社会倡议、培训和个人进步？

除了资金流失和交付缓慢之外，软件开发还有其他与高水平的技术债务直接相关的问题。

它给我们的生活带来了很大的压力。如果您经常处理有问题的代码，相对容易的任务可能会变成真正的怪物。

害怕做出改变是很常见的，特别是如果你是项目的新手。计划会议可能会没完没了，因为开发团队需要与项目管理进行讨论，以解释交付新功能的实际成本。

我们开始变得焦虑，因为我们不知道下一个挑战是一个大问题，还是在冲刺过程中难以修复的错误。

我们当中有谁没有过时的代码或不再维护代码？

这对我们来说是很常见的情况。这真的很复杂，因为我们需要接受随之而来的后果和问题。

通常会发生的情况是，您开始从过期的库或框架中复制和粘贴代码，然后自己修复问题。甚至，有时，复制整个项目并开始只使用您的克隆。

此外，我们可能仍然会发现与新工具的不兼容性。您可能想要使用新平台，但不能再使用新平台不再支持的旧版本工具。

想象一下，对于一个开发人员来说，在一个不再维护的javascript框架中工作了大约5年之后，想要在这个行业重新定位可能有多难。例如，这对他来说将是个人成本，需要从Reaction或Vue.js从头开始。

我们习惯使用的许多概念甚至可能在旧工具中缺失。

如果你的团队没有足够的心理健康和时间以最好的方式适应新的规模，那么你工作的公司每年增长300%或400%是没有意义的。这种情况在初创公司场景中相当常见，在一些虚幻的目标或半夜需要醒来让一些停机的服务启动和运行的时候，美化过长的工作时间。

在一个现实和受人尊敬的世界里，机器应该照顾这些情况，而不是我们。

事实上，在铁塔的情况下，它是一个错误，成为一个功能，哈哈！

它不会掉下来，即使它时不时地倾斜。比萨地标的情况受到了控制，即使游客坚持“拿着”它拍照。

同样的事情也可能发生在约翰的项目上。如果我们应用所有可行的解决方案，我们可能很容易拥有可持续发展的软件。

我在这次演讲中使用的所有参考资料都在Labcode的Github上的一个令人敬畏的列表中。

我们有一份两周一次的时事通讯，里面有我们在这里读到的最好的链接。在http://bit.ly/labcodesnews上注册就可以收到它。

如果你喜欢这篇文章，请随意分享，这样其他人也可以欣赏它。谢谢：)