静态分析可以代替代码审查吗？

在上一篇文章中，我解释了如何正确进行代码审查 。 我建议利用诸如Findbugs，PMD，Klocwork或Fortify之类的静态分析工具在将代码传递给审阅者之前检查常见错误和错误代码，以使审阅者的工作更加轻松并提高审阅效率。

一些读者问是否可以使用静态分析工具代替手动代码审查。 手动代码审查会增加开发的延迟和成本，而静态分析工具会不断变得更好，更快和更准确。 那么，您是否可以像许多团队自动化功能测试一样，使代码审查自动化？ 您是否也需要进行人工审核，还是可以依靠技术为您完成工作？

让我们从了解静态分析错误检查工具的优缺点开始。

静态分析工具可以做什么–不能做什么

在本文中 ，GrammaTech的Paul Anderson很好地解释了静态分析错误查找的工作原理，召回（找到所有实际问题），精度（最小化误报）和速度之间的权衡，以及使用静态分析工具查找错误。

静态分析工具非常擅长捕捉某些类型的错误，包括内存损坏和缓冲区溢出（针对C / C ++），内存泄漏，非法和不安全的操作，空指针，无限循环，不完整的代码，冗余的代码和无效的代码。

静态分析工具会知道您是否在错误地调用库（只要它能够识别该函数），是否错误地使用了语言（编译器可以找到但找不到的东西）或不一致（表明程序员可能拥有该语言）误会了）。

静态分析工具可以识别具有可维护性问题的代码，这些代码不遵循良好实践或标准，结构复杂或结构不良，并且是重构的理想选择。

但是这些工具无法告诉您什么时候您错了需求，或者什么时候忘记了某些重要内容或错过了一些重要的事情–因为该工具不知道代码应该做什么。 一个工具可以发现常见的一对一错误和一些无穷循环，但它不会捕获应用程序逻辑错误，例如按降序而不是升序排序，或者在您打算乘以除法时除法，在有条件时引用买方是卖方，还是承租人而不是出租人。 这些错误也不会在单元测试中发现，因为编写代码的人是编写测试的人，并且也会犯同样的错误。

工具找不到缺少的功能或未实现的功能，或者找不到应有的功能。 他们找不到工作流程中的错误或漏洞。 或监督审核或日志记录。 或调试意外遗留的代码。

静态分析工具可能能够找到一些后门或陷阱门-至少是简单的后门或陷阱门。 而且他们可能会发现一些并发问题 -死锁，竞争和错误或锁定不一致。 但是他们也会想念很多。

诸如Findbugs之类的静态分析工具可以为您执行安全性检查：不安全的调用和操作，使用弱加密算法和弱随机数，使用硬编码密码以及至少某些情况下XSS，CSRF和简单SQL注入。 进行过程间和数据流分析（查看源，汇和之间的路径）的更高级的商业工具可以发现其他错误，包括难以手动跟踪且耗时的注入问题。

但是工具无法告诉您您忘记了加密重要的数据，或者您不应该首先存储一些数据。 它无法找到关键安全功能中的逻辑错误，是否可能泄露敏感信息，是否在访问控制中检查错误，或者代码是否无法打开而不是关闭而失败。

仅仅使用一个静态分析工具来检查代码可能还不够。 对静态分析工具的评估（例如NIST的SAMATE项目（一系列比较研究，其中许多工具针对同一代码运行））显示，不同工具发现的问题之间几乎没有重叠（除了一些常见的领域，例如缓冲区错误） ），即使这些工具本应进行相同类型的检查。 这意味着要充分利用静态分析，您将需要针对同一代码运行两个或多个工具（例如SonarQube ，它将自己的静态分析结果与其他工具（包括流行的免费工具）集成在一起，为您做）。 如果您要购买商业工具，那可能很快就会变得非常昂贵。

工具与手动审核

工具可以发现编码错误或打字错误的情况，但思路不正确。 这些都是您必须通过手动检查发现的问题。

2005年的一项研究， 将Bug查找工具与评论和测试进行了比较，在5个不同的代码库上使用了开源Bug查找工具（包括Findbug和PMD），将发现的工具与通过代码审查和功能测试发现的工具进行了比较。 静态分析工具只发现了手动审核中发现的错误的一小部分，尽管这些工具更加一致–手动审核人员错过了一些工具被窃取的案例。

就像人工审核一样 ，这些工具发现的可维护性问题比实际缺陷要多（部分原因是所评估的工具之一-PMD-专注于代码结构和最佳实践）。 测试（黑盒-包括等效性和边界测试-以及白盒功能测试和单元测试）发现的错误少于评论。 但是不同的错误。 测试中发现的错误与静态分析工具发现的错误之间完全没有重叠。

发现可能发生或确实发生的问题

静态分析工具善于发现“可能发生”的问题，但不一定发现“确实发生”的问题。

科罗拉多州立大学的研究人员针对不同版本的不同开源项目运行了静态分析工具，并将这些工具所发现的内容与开发人员在过去几年中所做的更改和修复进行了比较，以查看这些工具是否可以正确预测修复需要进行的修改以及需要重构的代码。

这些工具在代码中报告了数百个问题，但很少发现开发人员最终解决的严重问题。 一个简单的工具（Jlint）找不到开发人员实际修复或清除的任何内容。 在一个项目中修复的112个严重错误中，静态分析工具也仅发现3个。 在另一个项目中，这些工具实际发现并修复了136个错误中的4个。 开发人员确实修复的许多错误都是诸如空指针和不正确的字符串操作之类的问题，这些问题是静态分析工具应该擅长抓住的，但事实并非如此。

这些工具在预测应重构哪些代码方面做得更好：开发人员最终重构并清理了该工具报告的70％以上的代码结构和代码清晰度问题（PMD，一种免费的代码检查工具，特别好为了这）。

爱立信针对大型，经过良好测试的成熟应用评估了各种商业静态分析工具 。 在一个C应用程序上，一种商用工具发现了40个缺陷-没有可能导致崩溃的问题，但是仍然需要解决一些问题。 在另一个大型C代码基础上，该工具的发现结果中有1％被证明是足以修复的错误。 在第三个项目中，他们针对已知内存泄漏的旧版本C系统运行了2个商业工具。 一个工具发现了32个错误，另外16个：两个工具仅发现了3个错误。 令人惊讶的是，这两个工具都没有发现已知的内存泄漏-发现的所有错误都是新错误。 在具有已知错误的Java系统上，他们尝试了3种不同的工具。 这些工具均未发现任何已知的错误，但其中一个工具发现了团队同意修复的19个新错误。

爱立信的经验是，静态分析工具会发现很难以其他方式发现的错误。 但是， 很少有人使用静态分析来发现难以置信的错误 ，尤其是在生产代码中。

这在Google和Sun JDK 1.6.0上进行的另一项有关使用静态分析（Findbugs）的研究中得到了支持。 工程师使用该工具发现了许多真实的错误，但不值得付出修复的代价：故意的错误，掩盖的错误，不可行的情况，已经注定的代码，测试代码或记录代码的错误，旧代码的错误是“即将离开”或其他相对不重要的案例。 该工具发现的中高优先级正确性错误中，只有大约10％是真正需要修复的错误。

安全案例

到目前为止，我们主要关注静态分析检查，以检查运行时正确性和常规代码质量， 而不是安全性 。

尽管安全性是建立在代码质量上的，漏洞只是黑客寻找和利用的错误，但检查代码的正确性和清晰度对于安全的应用程序而言还不够。 在过去5到10年中，对静态分析技术的大量投资一直用于查找代码中的安全性问题，例如OWASP的前10名或SANS / CWE的25个最危险的软件错误中列出的常见问题。

在发现安全漏洞方面，与手动审核相比，有几项研究着眼于静态分析工具的有效性。 第一项研究是针对一个大型应用程序，该应用程序通过安全专家进行的结构化手动评估发现了15个已知的安全漏洞。 在代码中运行了两种不同的商业静态分析工具。 这些工具共发现了不到一半的已知安全漏洞-仅是最简单的安全漏洞，这些漏洞不需要对代码或设计有深入的了解。

当然，这些工具还报告了成千上万个其他问题，这些问题需要进行检查和限定，或者作为误报而丢弃。 这些其他问题包括一些运行时正确性问题，空指针和资源泄漏以及代码质量发现（死代码，未使用的变量），但是除手动安全性审查已发现的那些漏洞之外，没有其他实际的安全漏洞。

但这假设您周围有安全专家来审查代码。 要查找安全漏洞，审阅者需要了解代码（语言和框架），并且他们还需要了解要查找什么样的安全问题。

另一项研究表明这是多么困难。 雇用了30名开发人员对小型Web应用程序（一些安全专家，其他Web开发人员）进行独立的安全代码审查。 他们被禁止使用静态分析工具。 该应用程序有6个已知漏洞。 20％的审阅者没有发现任何已知的错误。 没有一个审阅者找到所有已知的bug，尽管有几个发现了研究人员未知的新XSS漏洞。 平均而言，有10位审阅者发现所有安全漏洞的机会只有80％。

而且，不是

静态分析工具对于使用诸如C / C ++这样的不安全语言（有多种工具来查找常见错误）或使用动态类型化脚本语言（如Javascript或PHP） （不幸的是，这些工具不够出色）的开发人员尤其有用，以及开始学习新语言和框架的团队。 在（例如）医疗设备和航空电子设备等高度管制，安全关键的环境中，（或应该）使用静态分析。 并且，直到更多的开发人员接受更多培训并更多地了解如何编写安全软件之后，我们所有人都需要依靠静态分析（和动态分析）安全测试工具来捕获漏洞。

但是静态分析不能替代代码审查。 是的，即使您很聪明地执行代码检查，代码检查也会花费额外的时间并增加开发成本–并且，聪明的代码检查包括在执行检查之前运行静态分析检查。 如果您想快速行动并编写优质，高质量和安全的代码，则仍然需要进行审查。您不能仅依靠静态分析。

翻译自: https://www.javacodegeeks.com/2014/09/can-static-analysis-replace-code-reviews.html