共计 2298 个字符，预计需要花费 6 分钟才能阅读完成。
许多工程团队都在致力掂量他们重构工作的有效性。让咱们看一下能够帮忙您掂量重构胜利的 5 个指标。
代码重构为开发人员提供了急需的精力劳动，我认为许多开发人员都能够与此相关。终日编写代码要求很高，尤其是在您每天创立新性能的状况下。这是一项沉重的工作，开发人员通常须要一些空间来思考代码库的整体组织并回顾能够改良的中央。
这正是代码重构所做的。它为开发人员提供了这种急需的精力劳动，并让他们有机会解决更高级别的代码库相干问题。然而，这也是依据代码库指南查看您的代码的好时机。没有代码库是完满的。违反准则的小谬误使其进入“次要”分支。
最重要的是，它缩小了 技术债权。开发人员有机会摸索代码库并理解他们未接触过的其余局部或性能。这是代码重构的一个很好的附带益处。
然而，许多团队都在致力掂量他们重构工作的有效性。团队领导或 CTO 常常须要向管理层报告。如果没有“硬”数字，就很难证实重构代码库所破费的工夫与开发新性能所破费的工夫是正当的。对于许多初创公司来说，压力始终存在。这种继续的压力使得很难证实代码库重构的合理性。
本文着眼于可用于掂量代码重构胜利的不同指标。
掂量重构胜利的指标
您能够施行几个指标来掂量代码库重构是否胜利。您不须要实现所有指标，因为代码重构依然是一项合乎逻辑的工作。然而，特定指标能够很好地表明重构是否胜利。
1. 凋谢代码库问题的数量
当凋谢代码库问题的数量一直增长时，这是代码库品质降落的危险信号。然而，除了作为危险信号之外，它还能够帮忙您跟踪重构工作的胜利。您的显著指标是在开始下一个 sprint 之前将凋谢代码库问题的数量缩小到零。
您心愿尽快解决这些问题，因为它们依然是绝对较小的问题。然而，当您的代码库随着工夫的推移而倒退时，小问题可能会变得复杂且耗时。你想防止这种状况，因为它会让你更加落后 – 在工夫和老本方面。
如果您想晓得如何跟踪和理解您的代码库的问题，请尝试 Stepsize VSCode 和 JetBrains 扩大。该工具将帮忙您：
- 将您的问题工具连贯到代码
- 在团队外部分享对于代码库中的定时炸弹的常识
- 确定问题的优先级并跟踪进度
2. 代码库中的 TODO 数量
通常，您不心愿在代码库中看到太多的 TODO。这是事件须要改良但没有踊跃解决的迹象。当您的代码库倒退时，TODO 的上下文可能会失落，从而难以了解原始问题，更重要的是，难以解决 TODO。
因而，应用重构时可从代码库中删除闲暇的 TODO 或 您能够查看上下文并在当前更快地解决它们的形式组织您的 TODO。
3. 失败的单元测试数量
许多代码库都蒙受单元测试失败的困扰。只有失败的单元测试的百分比放弃绝对较低，这不会威逼到您的代码库的品质。
不过，请注意失败测试的数量。这是开始代码重构并掂量代码重构胜利与否的危险信号。在开始新的 sprint 之前，您心愿将失败的测试数量缩小到接近于零。
4. 代码覆盖率
代码覆盖率指标与测量失败单元测试的数量密切相关。然而，要掂量代码重构的胜利与否，您还想晓得代码库的品质如何进步。掂量代码库品质的一种办法是掂量代码覆盖率，因为它告诉您能够信赖您的代码库的水平。如果测试编写正确，则更高的代码覆盖率通常会导致更高的代码品质。
没有代码库是完满的，然而，请尝试靠近 100% 的代码覆盖率。如果您没有资源通过测试齐全笼罩您的代码库，请确保笼罩整个代码中最要害的门路。这将帮忙您减少对代码的信赖。
常见陷阱： 重构代码时不要遗记编写、更新或更改测试。您不想改良代码，但要升高代码覆盖率。换句话说，重构和代码测试齐头并进。
5. 测量反复
掂量反复度不是您应该瞄准的高级指标。然而，在重构代码时，它依然是一个值得关注的指标。当代码库增长时，人们并不总是齐全了解代码库。因而，他们可能不晓得曾经存在一个帮忙库或函数，并创立一个具备雷同性能的新库或函数。同样的状况也常常产生在较大代码库中的模块上。
首先，尝试辨认反复代码并记下地位以掂量重构是否胜利。您能够从新拜访此列表以掂量在实现代码重构后从代码库中删除了多少行反复代码。
如何应用这些指标来改良你的重构过程？
如果您思考代码库重构，请不要在没有打算的状况下间接退出。您须要为重构过程设定指标和界线，以便更容易掂量胜利。
首先，您要 收集在此代码库重构冲刺期间要解决 的所有与代码库相干的问题。如果短少某些票证，请确保跟踪它们或创立问题。例如，查看您想要从代码库中删除的所有 TODO**。
一旦确定了要解决的问题，就能够 制订有助于跟踪重构胜利的指标。例如，您想删除三个反复的模块并将代码覆盖率进步 15%。
当初您曾经收集了所有问题并设定了指标，是时候分享无关代码库的常识以及为什么须要解决特定的问题了。如果您不解决问题，您能够解释问题的背景和对我的项目的影响。这也是分享代码库新局部常识的好时机，因而所有开发人员都能够跟上进度。
最初，优先思考您要首先解决的问题。您将无奈在重构周或您设置的任何工夫线内实现所有问题。因而，在解决不太重要的问题之前，请确保首先解决影响最大的组织问题。
要完结代码库重构，请 收集所有指标数据并依据您设定的指标对其进行验证。当初是探讨出了什么问题以及未来如何改良代码库重构过程的好时机。不要指望一切顺利。可能会产生谬误，这很好。
论断：重构的胜利和目标？
无论您如何掂量重构胜利，请确保不要应用这些指标来评估程序员的体现或决定降职或相似的事件。
重构代码旨在尽早解决代码库和组织问题。如果不加以解决，它们可能会降级为更重大的问题，须要更多的工夫和资源来解决。
这也是组织代码重构的次要论据之一。在初创公司中，交付新性能的压力始终存在。然而，作为一个团队，有时您必须退后一步来评估代码并对其进行重构以 放弃其品质。
