何时停止遵循静态代码分析的建议？

Question

我现在对包含超过100.000行Java代码的项目使用静态代码分析已有一段时间了。我从Findbugs开始，它在开始时给了我大约1500个问题。随着时间的推移，我修复了最严重的问题并开始使用其他工具，如PMD，Lint4J，JNorm和现在的Enerjy。

随着更严重的问题被修复，存在大量低严重性问题。 您如何处理这些低优先级问题？

• 你尝试修理所有这些吗？
• 或仅在新编写的代码中？
• 您是否经常禁用某些规则？ （我发现我几乎可以使用任何可用的工具）。

如果你忽略或禁用规则，你会记录这些规则吗？你的经理们对“留下几千个低优先级问题没有修复”有什么看法？您是否在代码中使用（多个）工具特定注释，或者有更好的方法吗？

Answer 1

请记住，静态分析意味着产生大量误报;这是您为通常避免误报所支付的价格。也就是说，他们认为你更倾向于被错误地告知某些东西看起来很可疑（误报），而不是被告知实际某个问题的东西完全正常（假阴性）。

所以一般来说，你应配置这些工具，而不是接受现成的默认设置，这会产生很多噪音。

  

你尝试修复所有这些吗？

在我拥有技术控制权的项目中，我的标准运作方式是鼓励人们审查CI系统中所有新静态分析缺陷的文化。如果我们拒绝在特定类型的一段时间内修复足够的缺陷，我们会禁用该规则，因为它只会变成噪音。我们经常会看到禁用的规则，以确保它们仍然相关。

但是，一旦我们关闭了效率较低的规则，是的，我们就会修复所有缺陷。如果您认为某些问题存在，如果优先级不超过您必须执行的其他操作，则应该修复它。忽略它会破坏你团队的文化，并发出错误的信息。

  

如果你忽略或禁用规则，你会记录这些规则吗？

规则文件是我们项目的一部分，因此提交消息足以记录在此提交中禁用此类规则的事实。

  

你的经理们对“留下几千个低优先级问题并未修复”有什么看法？

无。我们确保他们了解我们正在做什么以及为什么，但他们通常（理所当然地）专注于更高级别的指标，如速度和整体项目健康。

Answer 2

  

你的经理们对“留下几千个低优先级问题并未修复”有什么看法？

我希望管理者优先考虑：决定（或被告知）任何任务是高优先级还是低优先级，并对人们花在高优先级而不是低优先级任务上的时间感到满意。

Answer 3

确定您希望在公司遵循哪些规则并禁用其余规则。您可以使用这些工具设置的规则的批次是主观样式问题，可以安全地忽略。您应该在公司样式指南中记录您在一次后遵循的规则（这样您就不会使用该信息使代码混乱）。

我不会仅根据静态分析工具的建议对旧代码进行更改。该代码已经过测试，可能正在运行。如果我需要进入代码并因任何其他原因进行更改，然后我将运行分析并进行其推荐的任何更改。

Answer 4

即使您最终决定不修复它们，关键在于我至少要审查所有问题。原因是，像苦难一样的错误，喜欢公司。我不能多次列举我发现了各种令人讨厌的臭虫，这些臭虫都没有报告;但是通过查看它所报告的看似不重要的人来找到它们。

Answer 5

如果您要查看错误跟踪数据库的类比，那么报告的大量错误是您可能永远无法获得的低优先级错误。当然，它们是真正的错误，你想修复它们，但大多数程序员在非常实际的约束下工作，没有时间解决所有问题。我最近写了一篇关于special nature of static analysis defects的文章。

解决静态分析错误的一个重要区别是，它们通常比定期报告的错误更容易处理。因此，快速扫描缺陷以识别不仅要修复的高优先级项目，而且还要识别最容易修复的项目可能是有用的。毕竟在开发过程中很早就发现了静态分析缺陷，并且非常清楚地说明了相关代码的特定部分。因此，你可能会在较低优先级的水果上捕获相当多的低水果。

我见过的各种策略包括： *首先，确保分析正确调整。静态分析带有出厂设置“开箱即用”，无法理解所有代码。如果你不能自己调整得到一些帮助（免责声明，我们提供一些类型的帮助）。你会降低误报率并找到更好的错误。 *确定大多数优先考虑缺陷的特征（它们可以是特定类别，代码的特定区域，静态分析工具提供的内置优先级评分等）。 *确定什么级别的阈值是重要的，并可能使其成为验收标准（例如，所有高级和关键需要解决） *确保解决阻碍验收标准的每个缺陷（解决意味着它至少必须被查看，因为有些可能是误报） *确保通过同行代码审查流程或通过尾端审核流程检查标记为误报的那些，这样您就不会有任何错误标记问题。

底线：选择要关注的内容，查看必要的内容，除非您的业务需求促成，否则不要修复所有内容

Answer 6

我个人觉得代码分析虽然有用但却被高估了。

我不能说Java，但使用C＃还有代码分析这样的东西。我同意它为你提供了很多聪明的想法，如何做得更好，但有时建议只是烦人。一些建议不是基于常识，而只是风格问题。经过一段时间玩代码分析后，我停止使用它。原因是我碰巧不同意许多警告，并且不想遵循这些建议。

一般来说，我建议做代码分析所说的。但到了某一点。无论谁编写规则定义的个人风格似乎都很容易被忽略。您可以为规则1添加例外，然后添加2，然后添加三个...直到它变旧。然后你只需停用该功能。