何时、为何以及如何进行代码分析

Adam Kolawa 博士访谈

您所说的“代码分析”是什么意思？

我的意思是静态分析代码，以监测其是否满足有关安全性、可靠性、性能和可维护性的统一预期。正确执行此操作，通过暴露结构性错误和防止整类错误，为生成可靠代码奠定了基础。我发现最有效的代码分析包括基于模式（基于规则）的静态分析、数据流静态分析和代码度量计算。

让我们更仔细地看看这三种静态分析。首先，基于模式的静态分析。它是什么？为何如此有价值？

通过基于模式的静态分析，我的意思是扫描代码，并检查它是否包含已知会导致缺陷或阻碍重用和敏捷性的模式。这包括监控对编码标准规则的合规性——防止不当语言使用的规则、满足行业标准（MISRA、JSF、Ellemtel 等）以及执行内部编码准则。

如果您在引入危险代码时就发现并修复这些问题，那么您将大大减少后续所需的测试和调试工作量——届时处理每个缺陷的难度和成本将增加一个数量级以上。

许多类别的缺陷都可以通过这种方式来预防，包括与内存泄漏、资源泄漏和安全漏洞相关的缺陷。事实上，仅使用静态分析来强制执行适当的输入验证就可以预防 OWASP（行业领先的安全社区）引用的约 70% 的安全问题。

什么是数据流静态分析？为何它有价值？

数据流静态分析会静态模拟应用程序的执行路径，这些路径可能跨越多个单元、组件和文件。这就像在不实际执行代码的情况下进行测试。它可以自动检测潜在的运行时错误，例如资源泄漏、NullPointerExceptions、SQL 注入和其他安全漏洞。这使得能够轻松地早期检测到关键的运行时错误，否则这些错误可能需要数周才能找到。

虽然基于模式的静态分析是一种错误预防实践，但数据流静态分析是一种错误检测实践。像所有错误检测实践一样，它不是 100% 准确的，您不能期望它能发现应用程序中潜藏的每一个错误。

基于模式的静态分析和数据流静态分析之间的主要区别在于，对于基于模式的静态分析，只要您发现并修复了已知会导致这些缺陷的代码结构，您就可以绝对保证某些类别的缺陷不会发生。对于数据流静态分析，您正在识别当真实应用程序路径被执行时可能发生的缺陷——而不仅仅是危险的代码结构。但您必须认识到，您不可避免地会忽略一些错误，并且可能比基于模式的静态分析具有更高的误报率。

如果数据流静态分析无法找到所有错误，您如何自动检测剩余的错误？

不幸的是，您无法做到。我花了 20 年时间研究错误是如何以及为何被引入软件应用程序的，我发现只有某些类型的错误可以自动检测到。大多数错误与需求实现不当、需求缺失或用户困惑有关，无法在不涉及人类智能的情况下识别。没有万能药。通过使用强大的技术集进行持续回归测试，您可以自动确定修改何时影响了应用程序行为，然后利用人类智能来确定更改是否是故意的。不过，那是另一篇论文的主题。

数据流静态分析最吸引人的地方在于，它是我所知道的唯一一项可以帮助您发现缺失需求的自动化技术。例如，假设数据流静态分析在 Java 应用程序中检测到了 NullPointerException。如果架构师检查了导致异常的路径，然后考虑了程序可能沿着该路径执行的条件，他可能会发现一个缺失的需求。也许异常是由某种可能发生的特定情况引起的，但由于没有人预料到这种情况会发生，所以从未实现处理该异常的代码。或者，也许有人以前实现了一个处理这种情况的代码分支，但在重构过程中被错误地注释掉了或删除了。这只是数据流静态分析如何帮助您发现代码中有趣之处的一个例子。

关于度量，为什么开发团队应该关注度量？

嗯，度量在静态分析中有有趣的历程。在大多数情况下，它们被忽略了。依我看，它们也应该被忽略……除非在某些情况下。

假设我有一百万行代码。如果我发现代码的平均圈复杂度为 9 或 6，这告诉我什么？什么都没有。

由于过度复杂的代码已被反复证明比简单代码更容易出错，我希望能有一种轻松的方法来关注复杂代码——例如，任何圈复杂度为 10 或更高的类或方法。测量传统度量没有坏处。然而，我认为能够标记超出行业标准或定制度量阈值的代码更有价值。

通过一种轻松的方式来聚焦于您认为过于复杂的代码，您可以确保它在同行代码审查中得到检查。

有意思……将度量作为同行代码审查的输入。其他类型的静态分析是否也与代码审查有关？

其他类型的静态分析也是同行代码审查的有价值的输入。如果开发人员不同意某个规则违规应该被修复（例如，因为他们认为规则在给定上下文中不适用），那么团队可以使用代码审查来讨论该违规是否是“抑制”的合适候选。此外，代码审查可以是一个很好的机会来分析数据流静态分析报告的缺陷；特别是，为了确定它们是否可能指示缺失的需求，正如我前面提到的。

当我们谈论静态分析和同行代码审查之间的关系时，还有一点很重要：当团队真正致力于使用针对其策略和优先级定制的规则集来运行静态分析时，在同行代码审查中就无需进行逐行检查。审查可以因此专注于检查算法、审查设计以及寻找自动化工具无法检测到的细微错误。这确实消除了同行代码审查过程中的许多繁琐工作——使其不仅更有效率，而且对开发人员来说更具吸引力。

我想这意味着应该在同行代码审查之前执行静态分析。关于何时执行，还有其他建议吗？

是的——至关重要的是持续进行，但要逐步引入。

有些人认为他们可以采取“大爆炸方法”：一次性扫描整个代码库，然后在某个里程碑（如发布）之前清理所有报告的问题。我见过很多人尝试过这种方法，但总是失败。为什么？这太压倒性了。

现实地说，如果您想确保代码符合您组织的指定编码策略，您需要使静态分析成为一个持续但不过分打扰的过程。首先，您配置静态分析工具，使其每天自动扫描项目代码库（从源代码管理），检查是否符合您的策略，并将结果报告给开发人员的 IDE。诀窍在于，您不是让它检查整个代码库，而是只检查自“截止日期”以来添加或修改的代码，该截止日期是您引入此计划的日期。否则，开发人员会被大量的报告违规行为压垮，最终不会修复任何一个。如果您专注于人们真正处理的代码，并要求在引入后一两天内修复违规行为，那么代码库就会缓慢但稳定地符合您的策略。

这种增量方法违背了行业中几乎所有人都在做的事情，尤其是在安全方面。在开发代码的同时，它需要每天都受到策略——安全策略、质量策略，或其他策略——的约束。如果他们能及时跟进，几乎不会影响团队的工作流程。事实上，考虑到它带来的错误预防的好处，它实际上会为他们节省时间。但如果他们放任不管，追赶将变得不堪重负。

唯一的例外是数据流静态分析。由于这实际上是一项错误检测练习，因此可以将其作为一个一次性行为来清理大型代码库。

您刚才提到了几次“策略”。您具体指的是什么？

策略是关于组织期望如何编写代码以及期望团队遵循哪些质量实践的总括性规定（例如，期望所有代码在发布前都经过同行审查，或者所有基于模式的静态分析违规行为在引入后一天内得到修复）。

基于模式的静态分析必须被视为一项策略。换句话说，您需要配置静态分析工具的所有安装，以检查代码是否按预期方式编写。然后，每次发现违规时，都必须立即修复，因为它违反了您的策略。工具的设置应根据需要进行微调，以确保不报告误报。误报会因“狼来了”效应而导致开发人员对所有违规（真实和虚假）变得麻木。

那么，您是否发现策略在实践中得到了真正的遵守？

当我被邀请拜访客户或潜在客户时，他们通常会先询问工具和功能。这是一个危险信号。当我们进一步交谈时，通常会发现他们之前购买了某种静态分析工具，告诉开发人员使用它，但没有获得预期的好处，因为开发人员从未真正开始使用它，或者他们最终停止使用它。

此时，我建议他们将重点从工具转移到流程。流程和工作流确实决定了静态分析计划的成败。您需要一个流程来确保静态分析不仅持续且一致地进行，而且以不干扰正常工作流程的方式进行。您需要将静态分析融入您现有的开发流程中。要实现这一点，流程必须是自动化的。静态分析工具在推动这种流程自动化方面发挥着重要作用，但它不是万能的。

举个例子：找一个开发人员声称“按需”进行静态分析的团队——例如，开发人员从他们的桌面运行一个开源静态分析工具。问他们，如果您对整个代码库运行静态分析工具，是否会报告任何违规行为。很有可能，是的。这意味着他们只是在口头上遵守静态分析。如果没有有效的流程集成和自动化，静态分析的努力不可避免地会衰退。

您如何实现流程自动化？

自动化基础设施是关键。您希望它像一台精密的机器一样运行，这样以下任务每晚都会在后台自动执行

1. 扫描源代码存储库以访问最新代码，并提供对代码库更改的可见性。
2. 使用静态分析工具分析最新代码。
3. 将每个违规行为与负责引入它的开发人员进行匹配（使用通过扫描源代码控制系统收集的数据），然后分发给该开发人员。

早上，每位开发人员都可以进入他们的 IDE，然后导入他们编写的代码中发现的违规行为。为了促进快速修复，每个报告的违规行为都直接链接到相关的源代码。

我在《Automated Defect Prevention: Best Practices in Software Management》（自动化缺陷预防：软件管理最佳实践）一书中详细讨论了自动化基础设施。第一章可在 http://www.parasoft.com/adp_book 下载。

如果一个组织想开始进行静态分析，您建议第一步是什么？

承诺将其作为您流程的持续组成部分，并开始构建支持性基础设施来驱动该流程。至少，您需要一个集成的自动化基础设施来执行上述三个任务。

关于 Adam Kolawa

Kolawa 是 Parasoft 的首席执行官和联合创始人，Parasoft 是领先的软件解决方案和服务提供商，通过在整个 SDLC 中将质量确立为持续过程，帮助组织更快地交付更好的应用程序。Kolawa 被认为是软件开发主题的权威，也是推广可实现软件质量持续过程的成熟方法的领先创新者。2007 年，eWeek 杂志将他评为 IT 领域最具影响力的 100 人之一。

Kolawa co-authored 两本书——《Automated Defect Prevention: Best Practices in Software Management》（Wiley-IEEE, 2007）和《Bulletproofing Web Applications》（Wiley, 2001）——并为 O'Reilly 的《Beautiful Code》一书贡献了一个章节。他还为《华尔街日报》、《CIO》、《Computerworld》和《Dr. Dobb's Journal》等出版物撰写或贡献了数百篇评论文章和技术文章，并撰写了许多关于物理学和并行处理的科学论文。

Kolawa 拥有加州理工学院理论物理学博士学位。他获得了 15 项他发明的软件技术的专利。

© 2008 Parasoft Corporation

版权所有。Parasoft 及其中列出的所有 Parasoft 产品和服务均为 Parasoft Corporation 的商标或注册商标。所有其他产品、服务和公司均为其在美国和/或其他国家的相应持有者的商标、注册商标或服务标记。