如何用编程代码解决实际问题（研究了代码质量后）

如何用编程代码解决实际问题（研究了代码质量后）最近关于代码质量对业务影响的研究表明，一般来说，由于技术债务和糟糕的代码，公司平均浪费了开发人员 23%到 42%的时间。但似乎这还不够令人感到担忧，关于软件开发人员由于技术债务而导致的生产力损失的研究还发现，开发人员经常“被迫”引入新的技术债务，因为公司一直在用代码质量换取新功能等短期收益。因此，虽然原因不同，但结果是相同的——我们最终得到的代码的维护成本比原本的要高。在本文中，我们将通过探究最近关于代码质量的研究来探讨其影响。随着开发速度提高了两倍，bug 减少了 15 倍，完成时间的不确定性显著减少，代码质量的业务优势也就变得清晰了。让我们来深入探究一下，看看如何利用这些数字为自己创造优势。技术债务这种比喻的说法最初是开发人员向业务人员解释重构需求和权衡的一种方式。然而，这个词在今天有了更广泛的含义。组织之所以会承担技术债务，有多方面的原因。也许是因为我们试图通过牺牲代码质量来更快地

作者 | Adam Tornhill

译者 | 明知山

策划 | 丁晓昀

软件行业中的人都“知道”代码质量很重要，但从来没有任何数据或数字可以证实这一点。因此，健康的代码库的重要性在业务层面被大大低估了——超过 90%的 IT 经理缺乏管理技术债务的流程和策略。

在本文中，我们将通过探究最近关于代码质量的研究来探讨其影响。随着开发速度提高了两倍，bug 减少了 15 倍，完成时间的不确定性显著减少，代码质量的业务优势也就变得清晰了。让我们来深入探究一下，看看如何利用这些数字为自己创造优势。

定义技术债务

技术债务这种比喻的说法最初是开发人员向业务人员解释重构需求和权衡的一种方式。然而，这个词在今天有了更广泛的含义。

组织之所以会承担技术债务，有多方面的原因。也许是因为我们试图通过牺牲代码质量来更快地交付功能，也许是因为我们对业务的理解发生了变化，导致设计不再匹配，也许是因为我们的设计一开始就不合适？

因此，虽然原因不同，但结果是相同的——我们最终得到的代码的维护成本比原本的要高。

量化技术债务造成的浪费

最近关于代码质量对业务影响的研究表明，一般来说，由于技术债务和糟糕的代码，公司平均浪费了开发人员 23%到 42%的时间。但似乎这还不够令人感到担忧，关于软件开发人员由于技术债务而导致的生产力损失的研究还发现，开发人员经常“被迫”引入新的技术债务，因为公司一直在用代码质量换取新功能等短期收益。

然而，技术债务的影响比财务浪费更加深远。技术债务同样会影响开发人员的幸福感和工作满意度（参见 Graziotin 和 Fagerholm 在 2019 年撰写的关于软件工程师的幸福感和生产力的论文）。

很少有开发人员喜欢使用本来可以避免的糟糕代码。这样的代码导致我们在解决问题的过程中被困在压力和时间紧迫感之中。高利息的技术债务加剧了开发人员的流失。

这个问题并不局限于开发人员。在过去的几年里，我也看到过许多技术管理者放弃并离开。我还记得向一家知名公司 CEO 做过一场关于技术债务的报告。报告进行到一半时，这位 CEO 惊叫道：“现在我明白为什么前 CTO 会离开了。”未能得到缓解的技术债务的连锁反应在整个组织中严重地打击了士气。

我们是不是陷入了事倍功半的泥潭

拥有一个高效的软件团队是一种竞争优势。作为一家公司，如果我们想要在市场上站稳脚跟，需要快速对客户的需求做出反应，根据反馈采取行动，并持续创新。我们需要在更短的产品周期内实现这一点。

显然，这需要熟练的软件开发人员。不幸的是，软件开发人员全球短缺——我们不能继续雇佣更多的人，因为不存在。

考虑到这些限制，在技术债务上浪费一半的资源在我看来是一种糟糕的权衡。

作为一种思想实验，我们假设开发人员 42%的时间确实花在处理技术债务上。这意味着，如果你的组织中有 100 名工程师，你只得到相当于 58 人的产出。然而——这是关键——实际的浪费要比这多得多。100 人与 58 人之间的协调、管理和沟通开销是真实存在的。布鲁克斯定律告诉我们，增加人员数量是有代价的。在一个人员过剩的项目中工作是痛苦的：你花在同步会议上的时间比花在代码编辑器上的时间还要多。

探索代码库中的技术债务

技术债务的主要问题是代码缺乏可见性。代码是一种抽象的概念，不是组织的所有成员都可以理解。因此，即使我们意识到了普遍存在的问题，仍然很容易忽略掉技术债务。对代码库进行量化和可视化是关键，对于工程团队以及产品和管理来说都是如此。

可视化是很奇妙的，因为它让我们进入已知宇宙中最强大的模式探测器：人脑。我在“Your Code as a Crime Scene”中深入探索了这一概念，并在 2015 年创建了 CodeScene，以便让普通观众能够使用这些技术。

我们使用的可视化方法学习起来很快。一旦找到了这些方法，可以用它们来指出代码库中的强点和弱点，以此来增强整个组织。此外，可视化可以让你评估潜在问题的深度。

我来分享一个来自两个流行的开源项目的例子。

在前面的可视化中，每个圆对应一个带有源代码的模块。颜色反映了代码的健康状况（参见“管理技术债务”，以获得更深入的了解）：

• 绿色的代码易于理解，风险低；
• 黄色表示警告，存在技术债务；
• 红色的代码表示存在严重的维护问题和技术债务。

对代码的运行状况进行可视化是坚实的第一步。然而，技术债务的实际成本是你为使用了不符合标准的代码所支付的利息。为了确定利息，我们需要了解组织如何处理正在构建的代码。让我们看看它是如何工作的。

根据利息来考虑技术债务优先级

技术债务的利息不能仅从代码中计算出来。幸运的是，我们可以通过像 Git 这样的版本控制系统来获取这些关键信息。特别是我们可以获取每段代码的变更频率，即提交的数量，并用它们来了解代码对开发人员的影响。将其与一些复杂性指标（如代码健康状况）相结合，我们就可以识别出需要经常处理的复杂代码。我称之为交叉热点。

热点为我们提供了相关性维度，而代码健康与质量维度相辅相成。为了管理技术债务，我们需要两个维度。下面是一个来自真实代码库的例子。

热点的最大优势在于，它们将信息限制在可操作的范围内。作为一个组织，我们不能也不应该一次性重构和重新设计所有的代码。热点让我们能够平衡短期目标，比如新特性和代码库的长期可持续性。

通过达到这种平衡，我们可以系统地偿还技术债务，并腾出时间进行有价值的创新。这些结果可能可以真正地改变游戏规则。Carterra的案例是一个很好的例子，这是一家领先的生物技术研究公司，报告称在解决了他们的热点问题后，计划外工作减少了 82%。通过精确识别正在开发中的文件及其相关的代码健康状况，Carterra 可以确定他们的工作优先级。

可度量的代码质量业务影响

有了代码健康状况和热点之后，我们就有了进行完整循环所需的一切。如果没有可量化的业务影响，就很难有理由投入资源去偿还技术债务。当代码持续恶化时，我们使用的任何指标都有被视为虚荣指标的风险。我们不希望这样的事情发生。

正如之前所说的，我们以前找不到能够证实高代码质量重要性的数据。在我们的红色代码白皮书中，我们调查了来自不同行业和领域的 39 个商业代码库，以此来改变这种状况。

红色代码白皮书表明，代码质量对发布时间和产品的外部质量都有显著的影响。

• 红色代码中的缺陷平均数量是健康代码库的 15 倍。这种缺陷密度会给产品带来不合格的体验。
• 红色代码造成了大量的浪费。向红色代码中添加一个特性所需的平均时间是绿色代码的两倍多。
• 在红色代码中实现一个特性所需的时间是绿色代码的 9 倍。

在这些发现当中，最重要的是低质量代码的不可预测性。向健康的代码中添加特效似乎是一个可预测的过程。数据表明，在不健康的红色代码中添加新特性在时间方面有显著的变化，可能要长 9 倍。这给组织带来了不确定性。

我将通过一家持有红色代码的虚拟公司来详细说明这种不确定性意味着什么。这家公司可能能够在 9 个月内实现一种新特性。如果他们的竞争对手持有绿色代码，他们可以在一个月内实现相同的特效。这家公司很难跟上竞争对手的步伐。可见代码质量是一个真实的、可度量的竞争优势。

代码质量和前进速度是相关的

在我从事软件行业的 25 年里，有很多人告诉我，我们没有时间做 X。X 可以是重构、适当的单元测试，或者重新调整架构以适应变化的业务环境。似乎存在一种误解，认为速度和质量是相互排斥的。红色代码白皮书的数据表明，实际上不存在这样的权衡。而事实恰恰相反——我们需要高质量的代码才能快速前进。

对于我来说，吞吐量的增加很大程度上是不确定性降低的结果。简单的代码可能造成的意外更少，造成破坏的风险也更低。健康的代码还反映了强大的工程文化，这很可能说明组织有其他一些重要的实践。

最后，值得注意的是，红色代码的发现表明了一种类似于之前由 Accelerate/DORA 研究提出的关系理论——部署周期越短，生产故障就越少。

处理遗留代码或低质量代码

代码健康指标清楚地表明我们需要保持较高的标准。然而，大多数时候我们并没有编写新的代码，我们也需要处理遗留代码。那么如何在这种情况下应用这些指标呢？

大规模处理遗留问题和代码质量问题具有一定的挑战性。在过去的十年里，我有幸分析了 200 多个代码库。我发现行为代码分析技术是必不可少的。我使用这项技术的过程概述如下。

1. 获取情形意识——主要问题出在哪里、问题有多严重、问题的深度如何？
2. 用一种能够让所有涉众（工程和管理）分享想法的语言进行总结。我们前面看到的代码健康状况可视化技术就是为此目的而设计的。
3. 根据影响情况来安排优先级——一个常见的错误是设定量化目标（例如，“我们将在 N 个月内将代码质量的问题数量从 5000 个减少到 2500 个”)。问题是，组织不需要解决所有的技术债务。这是对技术债务的一种常见误解，源于忽略了技术债务的利息。

1. 低利息债务可能是我们未来需要关注的风险，但绝对不是当务之急，我们可以把它们看作是免费贷款。
2. 我们要重点解决热点问题，优先解决高利息债务。在进行这种区分时，热点分析是必不可少的。

1. 让相关进展可见。在美国，很多组织都会将代码健康状况指标作为 KPI，我自己也发现这样做很有价值。然而，真正的进展是通过业务结果来衡量的。我建议将吞吐量指标与以质量为中心的反馈循环结合起来。具体地说，我已经看到了衡量计划外工作数量的趋势的价值（例如，bug 修复、生产崩溃——任何不在路线图上的事情）。
2. 在偿还了技术债务后，计划外工作的数量也会减少，正如我们在前面的案例研究中看到的那样。这使得开发更加可预测，而且组织可以专注于开发令人兴奋的特性，而不是被动地修复问题，这是一个很大的好处。我在我的白皮书“The Business Costs of Technical Debt”中提到了相关细节。

对技术债务采用数据驱动的方法

在本文中，我们看到由于技术债务造成的浪费是巨大的，并带来了实实在在的业务风险。为什么这种浪费会被容忍，一种解释可能是因为技术债务的影响在以前不可能在源代码级别进行量化。

本文介绍的红色代码研究为我们提供了挑战现状并将代码质量提升到业务 KPI 级别的方案。结合热点分析技术，我们甚至让这些发现变得具有可操作性。作为一家软件公司，区分红色代码和绿色代码有助于你通过数据驱动的方法来解决技术债务。

作者简介：

Adam Tornhill 是一名工程学和心理学学位的程序员。他是 CodeScene 的创始人，这家公司专门设计软件工程智能工具。Tornhill 是多本技术书籍的作者，包括畅销书“Your Code as a Crime Scene”，也是一位获过奖项的软件研究人员。Tornhill 的其他兴趣还包括音乐、武术和复古计算机。

原文链接：

https://www.infoq.com/articles/business-impact-code-quality/