静态代码分析与 Spring 和其他抽象的配合效果如何？
我所处的情况是，我需要至少做出一些努力来从源代码中删除从未使用过的代码。一般偏好是使用静态代码分析工具。我们在其他项目中对此非常幸运，但我听到的人大多是从事设备级代码工作的 C/C++ 开发人员。
我是一名 Web 开发人员，致力于 Java EE 系统。最受欢迎的分析工具是 Coverity Prevent，尽管我可能会提倡使用其他工具，如果我可以强有力地证明它更适合我们正在开发的技术。
我发现自己很怀疑——当您针对具有大量抽象的系统运行时，静态代码分析对死代码的有效性如何？例如我们使用Spring的依赖注入，以及JSF。在这两种情况下，都没有简单的方法来跟踪从前端到后端的函数调用，并全面了解什么被调用，什么没有被调用。
我非常担心死代码检查的误报将超过运行该工具的价值。
这个场景的体验如何？当您的架构使用大量抽象时，您是否设法从静态代码分析工具中获得价值？您需要采取什么措施才能使其以最少的误报发挥作用吗？
I'm in a situation where I'm required to make at least some effort to remove never-used code from my source code. The general preference is to use a static code analysis tool. We've had great luck with this in other projects, but the folks I hear from are mostly C/C++ developers working on device level code.
I'm a web developer working on a Java EE system. The favored tool for analysis is Coverity Prevent, although I could probably advocate for something else if I could make a strong case that it was more appropriate to the technology we're developing with.
I find myself dubious -- what the effectivity of static code analysis for dead code, when you are running against a system with a lot of abstractions? For example, we use Spring's dependency injection, as well as JSF. In both cases, there's no easy way to trace through the function calls from front end to back end and make a complete picture of what gets called and what doesn't.
I'm very concerned that the false positives on a dead code check will outweigh the value of running the tool in the first place.
What is the experience with this scenario? Did you manage to get value from a static code analysis tool when your architecture used a lot of abstractions? Was there anything you had to do to get it to work with a minimum of false positives?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我之前在 Coverity 工作，负责 Java 静态分析产品。
对于静态分析器来说，查找死代码这一特定任务可能是偶然的。特别是对于死方法，即无法在运行时调用的方法，如果您没有进行大量调整来通知静态分析器有关所有动态入口点的信息，误报率将非常高。
对于方法内的死代码，如果您的分析器具有该功能，则结果应该非常好，因为分析不会对输入数据做出任何假设。即使假设所有可能的输入，也有可能找到死代码，其中相关逻辑阻止采用某些分支。
I previously worked at Coverity, on the Java static analysis product.
This particular task of finding dead code can be hit-or-miss for a static analyzer. For dead methods in particular, meaning a method which cannot be called at runtime, the false positive rate will be very high without a lot of tuning from you to inform the static analyzer about all the dynamic entry points.
For deadcode within a method, if your analyzer has that capability, the results should be pretty good, as the analysis will not make any assumptions about the input data. Even assuming all possibe inputs, it is possible to find dead code where correlated logic prevents certain branches from being taken.
您可以使用测试覆盖率工具（动态分析）来确定您的系统使用了哪些代码；补码是可能已死的代码（它没有被执行！）并且需要检查（例如，可能存在一些误报）。您对系统进行的锻炼越多，误报率就越低。
可以在此处找到可以为您收集此数据的 Java 测试覆盖率工具。
如果您想最大限度地减少误报，您可以考虑运行静态分析工具和测试覆盖率，并进行交集。
一般来说，检测死代码X需要证明不存在调用X的条件。当面对图灵机和 IF 语句时，这是很难的（理论上是不可能的），
这就是为什么静态分析工具对此有很高的误报率。
然而，在许多情况下，“死代码”实际上只是根本无法调用它的代码（用 FAA 的话说就是“无效代码”）。也就是说，当定义了 X 时，系统中的任何地方都不会直接或间接地调用 X（或访问，如果 X 是数据项）。静态分析工具更容易检测到 Java 中动态类加载和反射的混乱复杂性（这使得面对未知但可加载的类不可能出现非活动代码分析问题）。
忽略这些复杂性，我们可以找到静态分析工具来检测大型 Java 系统中的非活动代码并报告它。这样的工具必须立即处理整个 Java 系统，因为否则引用可能存在于未包含在分析中的一个模块中。我们构建了一个“非活动”代码检测器和删除器甚至可以为您提供源代码返回并自动删除所有非活动代码，并报告未引用的内容。您检查报告，并决定是否要使用清理后的代码或添加对明显未使用的实体的访问权限。
You can use test coverage tools (dynamic analysis) to determine what code of your system is used; the complement is code that might be dead (it wasn't executed!) and needs inspection (e.g, there can be some false positives). The more exercise you give your system, the lower the false positive rate.
A Java test coverage tool that can collect this data for you can be found here.
If you wanted to minimize the false positives, you might consider running the static analysis tool and test coverage, and taking the intersection.
In general, detecting dead code X requires proving that there is no condition under which X is invoked. That's hard (theoretically impossible) when faced with a Turing machine and IF statements of the form
which is why static analysis tools have high false positive rates for this.
In many cases, however, "dead code" is really just code that simply has no way to invoke it ("deactive code" in FAA parlance.). That is, while X is defined, there are simply no invocations of X (or accesses, if X is a data item) anywhere in the system, directly or indirectly. These are easier for static analysis tools to detect with the messy complication in Java of dynamic class loading and reflection (which make the deactive code analysis problem impossible in the face of unknown but loadable classes).
Ignoring these complications, one can find static analysis tools that detect deactive code in large Java systems and report it. Such a tool has to process the entire Java system at once because otherwise a reference might exist in the one module not included in the analysis. We have built a "deactive" code detector and remover can even provide you your source code back with all the deactive code automatically removed, as well as report on what's unreferenced. You inspect the report, and decide if you want to use the cleaned up code or add an access to an apparantly unused entity.
在进行静态分析时，我不知道有任何静态分析工具实际上可以与抽象一起使用。您很可能必须编写一个模块来连接分析过程以及有关您使用抽象的方式的原因。
我怀疑死代码的存在成本比这还要高。
Working on static analysis, I am not aware of any static analysis tool that actually works with abstractions. You most likely will have to write a module that hooks into analyzing process and reasons about the way you use abstractions.
And I doubt that dead code presence costs more than this.
仅当您完全理解分析过程和代码时，才应在每种情况下进行静态代码分析。问题很简单，它只是粗糙的并且提供了假设。既不是解决方案，也不是完全准确的漏洞检查。您必须能够使用其他测试方法来确定误报。
静态代码分析器的价值不是代码审查。为了消除死代码，我将使用代码覆盖率来分析它。
- 就你而言 - 你提到了很多抽象......我几乎猜静态代码分析是不够的。
Static code analysis in every case should only be done if you completely understand the analysis-process and the code. The problem simply is, that it's just rough and offering assumptions. Neither a solution, nor a completely accurate check for vulnerabilities. You have to able to determine the false positives with other testing methods.
The value of a static code analyser is not a code-review. To eliminate dead code I'd use code-coverage to profile that.
- In your case - you mentioned many abstractions... I pretty much guess static code analysis won't be enough.