许多工程团队都在努力衡量他们重构工作的有效性。让我们看一下可以帮助您衡量重构成功的 5 个指标。

代码重构为开发人员提供了急需的精神休息，我认为许多开发人员都可以与此相关。整天编写代码要求很高，尤其是在您每天创建新功能的情况下。这是一项繁重的工作，开发人员通常需要一些空间来思考代码库的整体组织并回顾可以改进的地方。

这正是代码重构所做的。它为开发人员提供了这种急需的精神休息，并让他们有机会解决更高级别的代码库相关问题。但是，这也是根据代码库指南检查您的代码的好时机。没有代码库是完美的。违反准则的小错误使其进入“主要”分支。

最重要的是，它减少了 技术债务。开发人员有机会探索代码库并了解他们未接触过的其他部分或功能。这是代码重构的一个很好的附带好处。

然而，许多团队都在努力衡量他们重构工作的有效性。团队领导或 CTO 经常需要向管理层报告。如果没有“硬”数字，就很难证明重构代码库所花费的时间与开发新功能所花费的时间是合理的。对于许多初创公司来说，压力一直存在。这种持续的压力使得很难证明代码库重构的合理性。

本文着眼于可用于衡量代码重构成功的不同指标。

衡量重构成功的指标

您可以实施几个指标来衡量代码库重构是否成功。您不需要实现所有指标，因为代码重构仍然是一项合乎逻辑的工作。但是，特定指标可以很好地表明重构是否成功。

1. 开放代码库问题的数量

当开放代码库问题的数量不断增长时，这是代码库质量下降的危险信号。但是，除了作为危险信号之外，它还可以帮助您跟踪重构工作的成功。您的明显目标是在开始下一个 sprint 之前将开放代码库问题的数量减少到零。

您希望尽快解决这些问题，因为它们仍然是相对较小的问题。但是，当您的代码库随着时间的推移而发展时，小问题可能会变得复杂且耗时。你想避免这种情况，因为它会让你更加落后 - 在时间和成本方面。

如果您想知道如何跟踪和了解您的代码库的问题，请尝试 Stepsize VSCode和 JetBrains扩展。该工具将帮助您：

• 将您的问题工具连接到代码
• 在团队内部分享关于代码库中的定时炸弹的知识
• 确定问题的优先级并跟踪进度

2. 代码库中的 TODO 数量

通常，您不希望在代码库中看到太多的 TODO。这是事情需要改进但没有积极解决的迹象。当您的代码库发展时，TODO 的上下文可能会丢失，从而难以理解原始问题，更重要的是，难以解决 TODO。

因此，使用重构时可从代码库中删除空闲的 TODO 或 您可以查看上下文并在以后更快地解决它们的方式组织您的 TODO。

3. 失败的单元测试数量

许多代码库都遭受单元测试失败的困扰。只要失败的单元测试的百分比保持相对较低，这不会威胁到您的代码库的质量。

不过，请留意失败测试的数量。这是开始代码重构并衡量代码重构成功与否的危险信号。在开始新的 sprint 之前，您希望将失败的测试数量减少到接近于零。

4. 代码覆盖率

代码覆盖率指标与测量失败单元测试的数量密切相关。但是，要衡量代码重构的成功与否，您还想知道代码库的质量如何提高。衡量代码库质量的一种方法是衡量代码覆盖率，因为它告诉您可以信任您的代码库的程度。如果测试编写正确，则更高的代码覆盖率通常会导致更高的代码质量。

没有代码库是完美的，但是，请尝试接近 100% 的代码覆盖率。如果您没有资源通过测试完全覆盖您的代码库，请确保覆盖整个代码中最关键的路径。这将帮助您增加对代码的信任。

常见陷阱： 重构代码时不要忘记编写、更新或更改测试。您不想改进代码，但要降低代码覆盖率。换句话说，重构和代码测试齐头并进。

5. 测量重复

衡量重复度不是您应该瞄准的高级指标。但是，在重构代码时，它仍然是一个值得关注的指标。当代码库增长时，人们并不总是完全理解代码库。因此，他们可能不知道已经存在一个帮助库或函数，并创建一个具有相同功能的新库或函数。同样的情况也经常发生在较大代码库中的模块上。

首先，尝试识别重复代码并记下位置以衡量重构是否成功。您可以重新访问此列表以衡量在完成代码重构后从代码库中删除了多少行重复代码。

如何使用这些指标来改进你的重构过程？

如果您考虑代码库重构，请不要在没有计划的情况下直接加入。您需要为重构过程设定目标和界限，以便更容易衡量成功。

首先，您要 收集在此代码库重构冲刺期间要解决**的所有与代码库相关的问题。如果缺少某些票证，请确保跟踪它们或创建问题。例如， 查看您想要从代码库中删除的所有 TODO。

一旦确定了要解决的问题，就可以制定有助于跟踪重构成功的指标。例如，您想删除三个重复的模块并将代码覆盖率提高 15%。

现在您已经收集了所有问题并设定了目标，是时候分享有关代码库的知识以及为什么需要解决特定的问题了。如果您不解决问题，您可以解释问题的背景和对项目的影响。这也是分享代码库新部分知识的好时机，因此所有开发人员都可以跟上进度。

最后， 优先考虑您要首先解决的问题。您将无法在重构周或您设置的任何时间线内完成所有问题。因此，在处理不太重要的问题之前，请确保首先解决影响最大的组织问题。

要结束代码库重构，请 **收集所有指标数据并根据您设定的目标对其进行验证。**现在是讨论出了什么问题以及将来如何改进代码库重构过程的好时机。不要指望一切顺利。可能会发生错误，这很好。

结论：重构的成功和目的？

无论您如何衡量重构成功，请确保不要使用这些指标来评估程序员的表现或决定晋升或类似的事情。

重构代码旨在尽早解决代码库和组织问题。如果不加以处理，它们可能会升级为更严重的问题，需要更多的时间和资源来解决。

这也是组织代码重构的主要论据之一。在初创公司中，交付新功能的压力始终存在。但是，作为一个团队，有时您必须退后一步来评估代码并对其进行重构以 保持其质量。