基金静态收益率_您可以从静态分析中获得更多收益吗？-CSDN博客

基金静态收益率

在静态分析方面，软件研究员， Findbugs （最流行的Java静态分析工具）之父Bill Pugh是真正值得一听的少数专家之一。他并没有大肆宣传该技术以获取商业利益（Findbugs是一个免费的开放源代码研究项目），并且他基于在使用许多不同代码库（包括在Google上实现Findbugs）的实际经验，提供了一个平衡的观点。

他最近关于有效使用静态分析的演讲提供了一些有用的教训：

发展是零和游戏

花在检查和修复错误上的任何时间都花在设计和实施新功能，改善性能或与客户合作以更好地了解业务上，或者其他可能很重要的时间上。换一种说法：

“您不应该尝试修复代码错误的所有内容”

在Google，他们使用Findbugs发现了成千上万个真正的bug，开发人员修复了其中的许多错误。但是这些错误均未引起重大的生产问题。为什么？静态分析工具特别擅长发现愚蠢的错误，但并非所有这些错误都很重要。我们需要解决的是在“愚蠢而重要的交集”处的少数非常可怕的错误。

在过去的5年多的时间里，使用不同的静态分析工具，我们发现了一些真正的bug，一些杂音以及许多其他的“问题”，但这些问题似乎并不重要。像其他所有人一样，我们已经调整设置并滤除了对我们不重要或无关的检查。每天早上，一位高级开发人员会审查发现的内容（数量不多），抛出任何误报以及“谁在乎”和有意为之（“该工具不喜欢它，但我们故意这样做，我们知道它有用”）结果。剩下的就是一些确实需要每月解决的实际问题，还有一些我们认为值得做的代码清理问题（代码可以用，但是可以写得更好）。

另一个教训是，发现旧错误并不是那么重要或令人兴奋。如果代码已经运行了很长时间而没有任何严重的问题，或者人们不知道或不愿意忍受这些问题，那么就没有充分的理由回去解决它们了，也许还有一些很好的理由不去。修复旧错误，尤其是在您不太了解的旧系统中，是冒险的：尝试修复旧错误时，有5-30％的机会引入新错误。然后是部署补丁程序的成本和风险。没有实际的回报。当然，除非您一直在寻找“机器中的鬼影”，否则该工具可能已经找到了。或者该工具发现了一些您没有意识到的严重安全漏洞。

使开发人员使用静态分析的最简单方法是，专注于他们现在正在处理的代码中的问题-帮助他们在犯错误的同时发现错误。将静态分析检查集成到“持续集成”中并仅报告新发现非常容易（我所研究的所有商业工具都可以做到这一点，Findbugs也可以做到这一点）。但是最好是立即向开发人员提供反馈–这就是为什么像Klocwork和Coverity这样的商业供应商正在努力向IDE中的开发人员提供接近即时的反馈的原因，以及为什么像IntelliJ这样的IDE中的内置检查器如此有用。

充分利用静态分析

一年多以前，出于商业原因，我的团队改用了静态分析引擎。除了适应工作流程和表示形式的细微差别外，我们还没有看到使用一种工具或另一种工具之间的根本区别-每个工具针对同一组问题都有自己的命名和分类方案。新工具发现了一些以前没有的错误，并且不幸的是，它缺少一些我们过去依赖的检查，但是我们发现的问题数量或类型并没有很大的不同。我们也仍然使用Findbugs，因为Findbugs继续发现商业引擎不会发现的问题，并且不会增加检查的成本-很容易看到和忽略任何重复的发现。

早在2010年，我查看了Java静态分析工具的状态，并得出结论，核心技术已经有效地成熟了-供应商从静态分析技术中获得了尽可能多的好处，并且从那时起的改进将在于更好的包装反馈和工作流程，使这些工具更易于使用和理解。在过去的几年中，情况就是这样。最新版本的领先工具可提供更好的报告和管理仪表板，使跨分支的错误跟踪以及与其他开发工具的集成变得更加容易，并且云中几乎所有内容都已可用。

检查引擎变得越来越快，这在向开发人员提供反馈时非常有用。但是这些工具正在检查相同的问题，在这里和那里进行了一些调整。速度改变了开发人员使用工具的方式，但没有改变工具的功能。

根据过去2或3年中发生的情况，我预计Java的静态分析错误检测在这些工具可能会发现的各种问题中不会向前发展，至少直到/如果Oracle对Java 8或9中的语言进行了一些重大更改，或者需要使用新的检查器来检查新的错误类型。

自己做…

比尔·普格（Bill Pugh）承认，Findbugs至少和它即将获得的一样好。为了查找更多错误或更准确地查找错误，开发人员将需要编写自己的自定义规则检查器。大多数（如果不是全部）静态分析工具允许您使用其引擎的不同分析功能编写自己的检查器。
Cigital的Gary McGraw同意，静态分析的许多真正能力来自编写自己的检测器：

根据我们的经验，当组织逐渐走向定制时，它们将在静态分析实现中获得大部分好处。 例如，想象一下使用静态分析工具来提醒开发人员使用默认安全的Web门户API，并遵循安全的编码标准作为其夜间构建反馈的一部分。 （不幸的是，该行业的大部分经验仍然集中在实现基本工具上。）

如果工具提供者可以使程序员编写自己的规则变得简单明了，则为编写更高价值，针对项目和针对上下文的检查提供了可能性。强制执行模式，习惯用语和约定。实际上，比代码级检查更多的设计级检查。

静态分析工具可以扩展和定制的另一种方法是对源代码进行注释。 Findbugs，Intellij，Coverity，Fortify，Klocwork（以及其他我敢肯定的工具）可通过在源代码中添加注释信息来提高检查器的准确性，这些信息可用于工具可用于帮助跟踪控制流或数据流，或故意取消检查。

如果JSR-305势头强劲（本应将其放入Java 7中，但没有），并且工具供应商都同意遵循通用的注释约定，那么它可能会鼓励更多的开发人员尝试一下。否则，您需要对绑定到特定工具的代码库进行更改，这不是一个好主意。

但是这值得吗？

要使开发人员使用静态分析工具并修复工具发现的错误，需要花费大量工作。让开发人员花更多的时间来注释代码或理解和编写自定义代码检查器要困难得多，尤其是在当今这种技术状态下。它要求高水平的承诺和纪律以及强大的技术技能，我不认为回报会证明投资是合理的。

我们回到零和问题。是的，使用定制的静态分析工具可能会遇到更多问题，并且过滤掉的噪音也更少。但是，使团队将时间花在代码审查或配对上，或者将更多的时间用于设计和原型制作，或编写更好的测试，您将获得更大的回报。在高完整性的环境和顾问完成的专家工作之外，我看不到这些想法被采纳或对软件质量或软件安全性产生真正的影响。

参考： 您可以从静态分析中获得更多收益吗？来自我们的JCG合作伙伴 Jim Bird在Building Real Software博客中获得。