2022年衡量技术债务的8个主要指标

技术债务指标可帮助您监控当前代码库中的缺陷。今天我们要看看它们是如何工作的，并挑选出最好的跟踪工具。

就像信用卡上的账单一样，技术债务很容易失控。为避免这种情况发生，您需要跟踪您积累了多少债务。

技术债务指标旨在帮助您理解您收集的所有数据。现在有许多不同的指标可供选择，并且有大量用于记录数据的工具。

在这篇文章中，我们将了解它们的工作原理，并帮助您为您的业务选择正确的指标。

为什么技术债务对您的业务很重要

在我们深入了解细节之前，有必要先看看更大的图景。

技术债务 或代码债务是指代码中的任何缺陷，随着业务的增长必须纠正。你积累的技术债务越多，你在后期需要做的返工就越多。

当然，从头开始重建关键系统是低效的。除了您在原始开发阶段所做的任何投资之外，它还需要时间和金钱。

解决技术债务问题也可能让工程师士气低落——导致员工保留率下降——最终，用户将开始对你的劣质产品感到沮丧。

技术债务是太多了？

这一切听起来很可怕。然而，技术债务不一定是一场灾难。

就像你的信用卡一样，少量的技术债务是可以的。对于初创公司来说，这实际上是必不可少的。有时您需要推出 MVP 或基本产品作为概念证明。这可以帮助您筹集资金，用于偿还技术债务。

但是，如果您让债务堆积如山，您的业务最终可能会导致工程团队面临巨额“账单”。

流行的支付处理器 Stripe 实际上开始量化技术债务的成本。他们的研究发现，工程师平均花费33% 的时间来处理技术债务。在全球范围内，这是对全球 GDP 造成了 3 万亿美元的冲击。

衡量技术债务的 8 个指标

技术债务如此普遍的主要原因是许多企业甚至没有意识到他们拥有多少技术。只有当公司想要添加新功能时，问题才会出现。

为确保您不会落入同样的陷阱，最好设置一些技术债务指标。请注意，我们用复数形式说“指标”。没有单一的数据点可以让您准确了解您的技术债务。相反，您将需要使用一组指标来构建图片。

那么，您应该优先考虑哪些？这里有我们的最爱。

1. 新错误与已关闭错误

这是一个简单的开始。

每个已知的错误本质上都是一小部分技术债务。如果您想知道您的总债务，那么对您的工程师进行统计很重要。

假设您的工程师记录了错误何时修复，您可以计算出您管理技术债务的效率。如果新错误的数量超过已关闭的错误，则需要进行一些更改。

2. 债务指数

债务指数基于已解决问题与总问题的比率，其中优先级越高的问题权重越大。

如果您的工程团队定期跟踪代码库问题并确定其优先级，您可以轻松查看您有多少已解决和未解决的问题。您可以在问题跟踪器中跟踪它，但最简单的方法是使用 Stepsize VSCode 或JetBrains编辑器扩展，它们允许您直接从编辑器跟踪代码库问题并确定其优先级。此外，您将能够在仪表板上看到进度，这将激励您的团队解决更多的技术债务。

3. 代码质量

复杂的代码是技术债务不断增长的明确标志。在某些时候，有人不得不解开这个烂摊子。代码质量是量化代码整体质量和复杂性的几个指标的集合：

• 圈复杂度

• 类耦合

• 代码行

• 继承深度

对于这些单独的指标中的每一个，您的目标都是尽可能低的分数。代码质量的整体指标也是如此。

4. 周期时间

与代码质量密切相关的另一个指标是周期时间。

用技术术语来说，这衡量了第一次提交和部署之间经过的时间量。但是，当您衡量技术债务时，您需要研究对现有代码进行更改以及在不使用快速修复的情况下解决问题所需的时间。

如果您的工程师花费数小时修复小错误，您就会知道代码中潜伏着一些技术债务。

5. 代码流失

代码流失是一种衡量特定代码被删除、替换或重写的次数。

当您开发新功能或处理产品的特定部分时，不可避免地会出现一些流失。但是在你发布了一个新版本并修复了突出的错误之后，代码流失应该会开始迅速减少。

如果您在较长时间内看到代码的任何区域出现高流失率，则可能意味着每次迭代都会出现错误或快速修复。

6. 代码覆盖率

从某种意义上说，代码覆盖率度量是从相反的方向看同一个问题。

在这种情况下，您正在测量运行测试套件时执行了多少代码。这可以让您了解编写代码的效率 - 未使用的行越多，您编写的代码越有可能写得不好。

这里一个好的目标数字是 80%。高于这个分数是值得表扬的，而较低的分数表示有待完成的工作。

7. 代码所有权

在烹饪界，人们常说“厨师太多会破坏肉汤”。

同样的想法也可以应用于软件工程。如果你让太多人从事相同的任务，你很容易以一堆热气腾腾的垃圾告终。也就是说，您不希望只有一名工程师拥有整个项目的所有权。如果他们生病或离开您的组织，游戏就结束了。

出于这个原因，分析谁参与了哪些项目是一个好主意。作为流程的一部分，您应该计算为每个项目贡献*了多少工程师——这是您的*代码覆盖率。

平均数字将揭示您是否有一个有效的任务委派系统，或者一个免费的系统。理想的情况是有一个完整的团队负责每个项目。

8. 技术负债率 (TDR)

顾名思义，这个指标是专门为计算未来技术债务的总体成本而设计的。这可以是时间或其他一些资源。

方程比较简单：

（修复成本÷开发成本）×100 = TDR

在这种情况下，可以根据上述代码质量指标计算修复成本。

开发成本是构建产品或功能所需的代码行数除以每行平均资源消耗的简单计算。将两者放在您的 TDR 方程中，您最终会得到一个简单的比率，它告诉您需要花费多少时间或多少资源来解决问题。在理想情况下，您的 TDR 将在 5% 左右。如果您达到这个数字的倍数，那么早就该开始解决您的技术债务了！

额外惊喜：前端响应时间

前端的响应能力并非严格意义上的技术债务。但是，该指标可以作为警示灯。如果你的前端加载时间较长，一般是因为你的代码过于复杂或技术过时。两者都是技术债务的重要形式。

衡量技术债务的最佳工具

希望到现在为止，您应该开始了解您需要衡量什么来管理您的技术债务。剩下的就是决定使用哪些工具来完成任务。

以下是一些适合大多数项目的出色选项：

1.Stepsize

Stepsize 专为代码库问题跟踪而设计，可帮助您在最喜欢的编辑器中识别和突出显示问题。

Stepsize VSCode或 JetBrains 编辑器扩展是完全免费的，将帮助您跟踪您的技术债务并衡量您的进度。由于 Stepsize 与 Jira、Asana、Linear、Azure DevOps 等集成，您可以采用此应用程序而无需从根本上改变您的工作流程。

• 直接从您的编辑器创建和查看代码问题

• 跟踪代码改进并确定优先级，例如技术债务

• 通过问题跟踪器集成将关键问题添加到您的 sprint

2.SonarQube

SonarQube不是跟踪技术债务的完整解决方案，而是一个关注范围狭窄的工具。

该平台的主要目的是衡量和提高代码质量。SonarQube 通过自动分析突出显示错误和杂乱的代码，提供您可以随时间跟踪的数字和等级。

3. Teamscale

描述团队规模的最佳方式是作为产品的系统分析器。该工具评估代码的质量并通过可视化传递信息。

Teamscale 可以处理多个指标，并可选择配置自定义仪表板。该平台还提供了一些质量管理功能，尽管它缺乏 Stepsize 提供的带注释的问题跟踪和详细的技术债务分析。

4. Velocity by Code Climate

Velocity by Code Climate被称为“工程智能”平台，主要旨在帮助管理人员改进工作流程和分配资源。它不是专门为处理技术债务而设计的，但有一些交叉。

Velocity 从 Jira 和其他 DevOps 工具中提取数据以提供见解。您还可以运行自动代码分析，并通过内联问题报告收集信息。

5.Jira

衡量技术债务的一种方法是在您选择的项目管理工作流程中创建和监控积压工作。

如果这是您想要采用的方法，那么Jira是一个明显的选择。它不提供上述应用程序的任何代码分析功能，但它是管理任务的好平台。

结论

正如我们所发现的，有许多不同的方法来衡量和管理技术债务。如果您正在寻找多合一的解决方案，那么上述选项之一绝对应该在您的候选名单中。

请记住，所有高增长的软件公司总是承担技术债务。但重要的是要对其进行衡量并不断清理您的代码，以使您的公司保持增长。