静态代码分析与 Spring 和其他抽象的配合如何？答案

【问题标题】：How well does static code analysis work with Spring and other abstractions?静态代码分析与 Spring 和其他抽象的配合如何？
【发布时间】：2010-12-13 05:29:03
【问题描述】：

我的情况是，我至少需要努力从源代码中删除从未使用过的代码。一般偏好是使用静态代码分析工具。我们在其他项目中对此非常幸运，但我听到的大多数人都是从事设备级代码的 C/C++ 开发人员。

我是一名在Java EE 系统上工作的网络开发人员。最受欢迎的分析工具是 Coverity Prevent，尽管如果我能提出强有力的理由证明它更适合我们正在开发的技术，我可能会提倡其他东西。

我发现自己很怀疑——当您针对具有大量抽象的系统运行时，静态代码分析对死代码的有效性如何？比如我们使用Spring的依赖注入，还有JSF。在这两种情况下，都没有简单的方法来跟踪从前端到后端的函数调用，并完整地了解哪些被调用，哪些未被调用。

我非常担心死代码检查的误报会超过运行该工具的价值。

在这种情况下有什么经验？当您的架构使用大量抽象时，您是否设法从静态代码分析工具中获得价值？您是否需要做些什么才能让它以最少的误报工作？

【问题讨论】：

这似乎更像是一个社区 wiki 类型的问题。

标签： spring jsf static-analysis abstraction coverity-prevent

【解决方案1】：

我之前在 Coverity 工作，负责 Java 静态分析产品。

对于静态分析器来说，查找死代码的这一特殊任务可能是偶然的。特别是对于死方法，即无法在运行时调用的方法，如果您没有进行大量调整以告知静态分析器所有动态入口点，误报率将非常高。

对于方法中的死代码，如果您的分析器具有该功能，则结果应该非常好，因为分析不会对输入数据做出任何假设。即使假设所有可能的输入，也有可能找到相关逻辑阻止采用某些分支的死代码。

【讨论】：

【解决方案2】：

您可以使用测试覆盖率工具（动态分析）来确定您的系统使用了哪些代码；补充是可能已经死掉的代码（它没有被执行！）并且需要检查（例如，可能有一些误报）。您对系统进行的锻炼越多，误报率就越低。

可以在here 找到可以为您收集这些数据的 Java 测试覆盖率工具。

如果您想尽量减少误报，您可以考虑运行静态分析工具和测试覆盖率，然后取交集。

一般来说，检测死代码 X 需要证明不存在调用 X 的条件。当面对图灵机和 IF 形式的语句时，这很难（理论上是不可能的）

 if (Turing(..)) then call X();

这就是为什么静态分析工具对此有很高的误报率的原因。

然而，在许多情况下，“死代码”实际上只是无法调用它的代码（FAA 用语中的“无效代码”。）。也就是说，虽然定义了 X，但在系统中的任何地方都没有直接或间接地调用 X（或访问，如果 X 是数据项）。这些对于静态分析工具来说更容易检测到 Java 中动态类加载和反射的复杂复杂性（这使得在面对未知但可加载的类时无法进行非活动代码分析问题）。

忽略这些复杂性，可以找到静态分析工具来检测大型 Java 系统中的无效代码并报告它。这样的工具必须同时处理整个 Java 系统，否则分析中未包含的一个模块中可能存在引用。我们已经建立了"deactive" code detector and remover 甚至可以为您提供源代码，并自动删除所有无效代码，并报告未引用的内容。您检查报告，并决定是要使用清理后的代码还是添加对明显未使用的实体的访问权限。

【讨论】：

关于静态分析工具的程序不可能理论被夸大了。正如您的 Turing() 方法所引用的，停机问题是一个大问题，但它适用于优化编译器，没有人怀疑优化编译器的实用性。分析工具需要向用户提供证据，而用户不会相信复杂的证据链。这留下了相对平凡的东西，但这很有趣，因为一个工具可以找到代码库中广泛不同的问题，这对人类来说很难查明，但对人类来说很容易验证。
我并没有指责静态分析工具（我也构建了它们！），只是观察到理论限制保证它们在所有情况下都不能产生正确的答案。我同意正确的反应是使用静态分析工具，因为它们在处理复杂性方面比人要好得多，但要检查答案。 “信任，但要验证”。

【解决方案3】：

从事静态分析，我不知道有任何静态分析工具实际上可以与抽象一起使用。您很可能必须编写一个模块来分析您使用抽象方式的过程和原因。

我怀疑死代码存在的成本比这更多。

【讨论】：

【解决方案4】：

只有在您完全了解分析过程和代码的情况下，才应在每种情况下进行静态代码分析。问题很简单，它只是粗略并提供假设。既不是解决方案，也不是完全准确的漏洞检查。您必须能够使用其他测试方法确定误报。

静态代码分析器的价值不是代码审查。为了消除死代码，我会使用代码覆盖来分析它。 - 在你的情况下 - 你提到了很多抽象......我猜静态代码分析是不够的。

【讨论】：

这似乎是非常严格的建议。所以除非他们了解数据流分析的局限性，否则没有人应该使用 Findbugs？在您了解抽象解释的细节之前，Coverity 的产品是禁止使用的？如果你喜欢结果，那就去吧。无需确切了解分析是如何完成的。
但这正是我的意思：除非他/她熟悉数据流分析，否则任何人都不应该使用 FindBugs、PMD 或任何与静态代码分析相关的东西。否则人们倾向于试图避免检测，但无论如何都会产生相同的错误。只有非常成熟的程序员才能有效地使用静态代码分析来消除代码中的漏洞。发现问题的产品不写补丁，也不知道型号。