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

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

以下将介绍它们是如何工作的，并帮助企业为其业务选择正确的指标。

为什么技术债务对企业的业务至关重要

在深入了解细节之前，有必要先从整体的角度进行了解。

技术债务或代码债务是指代码中的任何缺陷，这些缺陷必须随着业务的增长而得到纠正。企业欠下的技术债务越多，那么在后期需要返工的工作就越多。

当然，从头开始重建关键系统的效率也很低下。除了在原始开发阶段所做的任何投资之外，它还需要耗费更多的时间和费用。

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

太多的技术债务是多少?

太多的技术债务听起来很可怕。然而，技术债务并不一定代表是一场灾难。

就像人们的信用卡一样，少量的技术债务是可以接受的。对于初创公司来说，这实际上是必不可少的一个举措。企业有时需要推出最小可行性产品(MVP)或基本产品作为概念证明。这可以帮助企业筹集资金，用于偿还技术债务。

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

当前主流的支付处理器Stripe平台实际上开始量化技术债务的成本。研究发现，工程师平均花费33%的时间来处理技术债务。在全球范围内，这对全球GDP带来了巨大的影响。

衡量技术债务的8个指标

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

为确保不会落入同样的陷阱，最好设置一些技术债务指标。并没有单一的数据点可以让企业准确了解其技术债务。与其相反，将需要使用一组指标来了解。

那么，应该优先考虑哪些指标?

(1)新错误与已关闭的错误

这里有一个简单的开始。每个已知的错误(Bug)本质上都是一小部分技术债务。如果企业想知道其总体债务，那么让工程师进行统计很重要。

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

(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的最佳方式是作为产品的系统分析器。该工具评估代码的质量，并通过可视化传递信息。

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

(4)Velocity by Code Climate

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

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

(5)Jira

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

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

结论

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

需要记住的是，所有高增长的软件开发商都会承担一些技术债务。重要的是要对其进行衡量，并不断清理代码，以使其业务保持增长。