您的代码库就像一个杂乱的车库

未使用的代码会增加维护代码库的时间和负担，删除它是除了“需要更多铃铛”之外唯一的解决办法。不幸的是，并不总是明显开发人员能否删除某些代码而不会破坏应用程序。随着代码库变得混乱和难以控制，开发团队可能被困扰在减慢开发速度和降低士气的神秘代码中。

你还记得第一次走进车库时的场景吗？那时空间是空的，闪闪发光，兀自躺着，充满着保护你的车辆和电动工具的承诺？最后一次走进去时是什么样子？如果你和我们许多人一样，长时间关闭的箱子的杂乱使你每次绕过它们时都感到挑衅，让你花费宝贵的时间才能找到你需要的物品，而车却停在车道上。遗憾的是，开发团队在源代码中也存在类似的问题，源代码已经混乱不堪。

在过去的几个月里，我一直在努力寻找一种帮助开发团队维护更少代码的方法。我们通常所读到的内容都是关于使用新框架、新工具和新技术-但我们中许多人忽略了的一点是通过简单地摆脱我们不再需要的东西来提高速度。当它运行时， JVM 流 从其第一次调用方法的日志流到中心位置，以跟踪“我们最近是否使用过此方法”。当该方法出现在代码清单中时，答案是肯定的-如果该方法未出现，则可被移除为未使用的代码的候选项。

死代码清除

如果您是一名资深开发人员帮助新成员，考虑将新成员纳入团队并且让他们学习代码库需要花费的工作。每次他们更改内容时，他们都要滚动查看方法。虽然我们的 IDE 和分析器可以识别完全死代码，但令人沮丧的是看起来活着但实际上没有被使用的代码。通常这些是公共方法或类，只是没有被调用或有已注释/修改的注解。当我与团队讨论我们囤积未使用代码的想法时，我听到了这样的评论：

• “我不知道这段代码是做什么的，所以我不想删除它，但我很乐意。”
• "我可以清理一下，但我有其他优先问题，没有时间做这个。"
• “我们从未给清理工作优先级。我们只做新功能。”

如果 Java 开发人员有一种更简单的方式识别 死代码以便移除-一种在我们的冲刺中可以优先考虑代码清理，从而减少技术债务而不会影响增加功能需求的方法，会怎样呢？

代码清理很复杂，通常被搁置于新功能之后。随着时间的推移，代码会变得未使用，因为团队进行重构而不是移除：对注释进行注释、更改路径或移动功能。大多数资深工程师必须在冲刺中分配时间找出要移除的东西：评估缺失的日志语句或使用静态分析器审查代码。从时间的角度来看，这两种方法都有问题，因此许多团队只是将其留在代码库中，活动但是已死：这是未来团队长的问题或者要推迟到下一次重大重写。然而，JVM 具有一个被忽视的功能可以识别死代码并简化优先考虑的问题。通过重新利用字节码解释器，JVM 可以识别每次执行时方法第一次被调用的时机。当在中心位置进行跟踪时，这些日志产生了一张宝藏地图，您可以根据这张地图移除死代码。减少整体认知负担并提高团队速度。如果一个方法一年没有运行过，那么很可能可以将其删除。然后，团队长可以取出未执行的类和方法，并在一次或者几次冲刺中移除那些代码。

为什么要移除未使用的代码？对于许多团队来说，更新库以及主要的 Java 版本需要触及大量代码。在 Java 8 和 Java 17 之间，XML 库被弃用和移除-当您移植应用程序时，您还在使用所有那些 XML 处理吗？如果代码不运行，团队成员就不应该花费时间更改代码并更新测试以使其通过：删除死代码更快，减少了弄清楚代码的心智复杂度。类似情况也会出现在主要框架的更新中，例如 Spring、iText 等。

想象一下你支付邻居的孩子用你的割草机为你割草，而它被藏在一个箱子、用尽电池、旧衣服和旧电子产品的墙后。在他们在为你的垃圾环绕前努力了多久之后，他们会放弃并回家？资深工程师也是这样做的。本来应该是一小时的割草工作变成了两个小时。

混乱和未使用代码的问题也会影响着致力于 分解单体 或为云重新架构的团队。在没有完全测量到仍在使用的代码的情况下，团队最终打破了庞大的微服务，因为它们包含了许多从单体架构中提取出来并不必要的部分。与其生成预期的简化套件的微服务，这些重新架构项目花费更多时间、成本更高，并且感觉需要立即进行重写，因为团队试图避免的杂乱从未被移除。团队要减少维护负担，需要很快地减少这种负担：删除不必要的代码是减轻负担的快速途径。与其呼吁重写，不如减轻维护负担来整理您现有的代码。

追踪 JVM 中的代码

JVM提供了许多功能，可以帮助开发团队创建运行速度快的应用程序。它已经知道方法将首次被调用的时间，因此与性能分析工具不同，它不会影响跟踪这种情况。通过整合这些首次调用的信息，团队可以识别未使用的代码，并最终整理那个不断增长的代码库。