如何在遗留项目中引入分析器，而不会让团队灰心丧气

尝试静态代码分析器很容易。但在一个老的大型项目的开发中引入它需要技能。如果方法不正确，分析器可能会增加工作，减慢开发速度，并打击团队的积极性。让我们简要讨论一下如何将静态分析恰当地集成到开发过程中，并开始将其作为CI/CD的一部分使用。最近，我对“静态分析入门”这篇文章很感兴趣，同时又不会让团队不知所措。一方面，这是一篇不错的文章，值得一读。另一方面，在我看来，对于如何在包含大量遗留代码的项目中安全地采用静态分析，它似乎没有提供一个完整的答案。这篇文章说，你可以忍受技术债务，只能使用新的代码，但它没有涵盖以后如何处理这些技术债务的问题。我们的PVS-Studio团队就这一主题提出了我们自己的观点。让我们来看看嵌入静态代码分析器的问题一般是如何产生的，如何克服这个问题，以及如何逐步无缝地消除技术债务。启动分析仪并查看其工作原理通常很容易[1]。您可以在代码中看到一些有趣的错误，甚至是可怕的潜在漏洞。您甚至可以修复一些东西，但在此之后，许多程序员放弃了。所有静态分析器都会发出误报。这是静态代码分析方法论的特殊性，对此无能为力。因此，这是一个无法解决的问题，赖斯定理[2]证实了这一点。机器学习算法也无济于事[3]。如果即使是一个人也不能总是分辨出某个特定的代码是否错误，那么您就不应该从程序中期待这一点：)。如果已经配置了静态分析器，则误报不是问题：如果我们谈论的是C或C++，则包含特定结构的宏会被标记(这会导致无用的对象出现在使用这些宏的每个地方)；

执行类似于系统功能的动作的自定义功能被标记(自定义模拟memcpy或printf)[4]；

在这种情况下，我们可以预期10-15%[5]量级的低水平假阳性。换句话说，10个分析器警告中有9个将指示代码中存在真正的问题，或者至少是“带有强烈气味的代码”。同意，这个场景非常令人愉快，分析器成为程序员真正的朋友。在现实中，在一个大型项目中，最初的情况会有很大不同。分析器对遗留代码发出成百上千的警告。不可能很快得到，这些警告中哪些是相关的，哪些是不相关的。坐下来开始处理所有这些警告是不理性的，因为这种情况下的主要工作将停止几天或几周。通常情况下，团队不能沉迷于这样的场景。此外，还会有大量的不同之处破坏变革的历史。快速批量修复代码中如此大量的片段将不可避免地导致新的打字错误和错误。最重要的是，在对抗警告的斗争中这样的壮举没有什么意义。您必须承认，由于该项目已经成功运行多年，其中的大部分关键错误都已经修复。是的，这些修复非常昂贵，你必须对它们进行调试，得到用户对错误的负面评论，等等。静态分析器将有助于在代码编写阶段快速且廉价地修复许多这样的错误。但目前，这些错误已经修复，分析器主要检测旧代码中的非关键错误。此代码可能不会使用，也可能很少使用，并且其中的错误可能不会导致明显的后果。按钮的某个地方的阴影可能是错误的颜色，但这并不妨碍任何人使用该产品。当然，即使是小错误也是错误。有时错误可能会隐藏真正的漏洞。然而，放弃一切，花几天/几周的时间来处理那些不显露的缺陷似乎是一个值得怀疑的想法。程序员不断地查看关于旧工作代码…的所有这些警告。他们认为：让我们不要进行静态分析。让我们去写一个新的有用的特性吧。从他们自己的角度来看，他们是对的。他们认为应该先消除所有这些警告。只有在此之后，他们才能从定期使用代码分析器中获益。否则，新的警告只会沉浸在旧的警告中，没有人会注意到它们。这与编译器警告是相同的类比。建议没有编译器警告并不是偶然的。如果有1000条警告，那么当它们变成1001条时，就没有人会注意到这一点，也不清楚到哪里去寻找这条最新的警告。这个故事最糟糕的部分是如果楼上有人强迫你