在大型java项目中,您使用什么工具来查找未使用的/死亡的代码?我们的产品已经开发了几年,手动检测不再使用的代码变得非常困难。但是,我们会尽量删除未使用的代码。

对于一般策略/技术(而不是特定工具)的建议也很感激。

编辑:请注意,我们已经使用了代码覆盖工具(Clover, IntelliJ),但这些帮助不大。死代码仍然有单元测试,并显示为已覆盖。我想理想的工具应该是识别那些依赖于它的其他代码很少的代码集群,从而允许手动检查文档。


当前回答

我很惊讶这里竟然没有提到ProGuard。这是目前最成熟的产品之一。

ProGuard is a free Java class file shrinker, optimizer, obfuscator, and preverifier. It detects and removes unused classes, fields, methods, and attributes. It optimizes bytecode and removes unused instructions. It renames the remaining classes, fields, and methods using short meaningless names. Finally, it preverifies the processed code for Java 6 or for Java Micro Edition. Some uses of ProGuard are: Creating more compact code, for smaller code archives, faster transfer across networks, faster loading, and smaller memory footprints. Making programs and libraries harder to reverse-engineer. Listing dead code, so it can be removed from the source code. Retargeting and preverifying existing class files for Java 6 or higher, to take full advantage of their faster class loading.

下面是列表死代码的示例:https://www.guardsquare.com/en/products/proguard/manual/examples#deadcode

其他回答

我很惊讶这里竟然没有提到ProGuard。这是目前最成熟的产品之一。

ProGuard is a free Java class file shrinker, optimizer, obfuscator, and preverifier. It detects and removes unused classes, fields, methods, and attributes. It optimizes bytecode and removes unused instructions. It renames the remaining classes, fields, and methods using short meaningless names. Finally, it preverifies the processed code for Java 6 or for Java Micro Edition. Some uses of ProGuard are: Creating more compact code, for smaller code archives, faster transfer across networks, faster loading, and smaller memory footprints. Making programs and libraries harder to reverse-engineer. Listing dead code, so it can be removed from the source code. Retargeting and preverifying existing class files for Java 6 or higher, to take full advantage of their faster class loading.

下面是列表死代码的示例:https://www.guardsquare.com/en/products/proguard/manual/examples#deadcode

我们已经开始使用Find Bugs来帮助识别代码库中目标丰富的重构环境中的一些缺陷。我还会考虑结构101来识别代码库架构中过于复杂的地方,这样你就知道真正的沼泽在哪里。

理论上,您无法确定地找到未使用的代码。这有一个数学证明(好吧,这是一个更普遍的定理的特殊情况)。如果你很好奇,可以查一下《停止问题》。

这可以在Java代码中以多种方式表现出来:

根据用户输入、配置文件、数据库条目等加载类; 加载外部代码; 将对象树传递给第三方库; 等。

也就是说,我使用IDEA IntelliJ作为我的IDE选择,它有广泛的分析工具,可以发现模块、未使用的方法、未使用的成员、未使用的类等之间的依赖关系。它也很智能,就像一个没有被调用的私有方法被标记为未使用,但一个公共方法需要更广泛的分析。

用户覆盖工具,例如EMMA。但它不是静态工具(也就是说,它需要通过回归测试实际运行应用程序,并通过所有可能的错误情况,这是不可能的:))

尽管如此,EMMA还是非常有用的。

我会让运行中的系统保持代码使用的日志,然后开始检查几个月或几年没有使用的代码。

例如,如果您对未使用的类感兴趣,那么所有的类都可以在创建实例时记录日志。然后,一个小脚本可以将这些日志与完整的类列表进行比较,以找到未使用的类。

Of course, if you go at the method level you should keep performance in mind. For example, the methods could only log their first use. I dont know how this is best done in Java. We have done this in Smalltalk, which is a dynamic language and thus allows for code modification at runtime. We instrument all methods with a logging call and uninstall the logging code after a method has been logged for the first time, thus after some time no more performance penalties occur. Maybe a similar thing can be done in Java with static boolean flags...