很长一段时间以来，我确实在一个包含超过 100.000 行 Java 代码的项目上使用静态代码分析。我从 Findbugs 开始，一开始它给了我大约 1500 个问题。随着时间的推移，我修复了最严重的问题，并开始使用其他工具，如 PMD、Lint4J、JNorm 和现在的 Enerjy。
随着更严重的问题得到解决，出现了大量的低严重性问题。你如何处理这些低优先级的问题？
如果你忽略或禁用规则，你会记录这些吗？您的经理对“留下数千个低优先级问题未解决”有何看法？您在代码中使用（多个）工具特定注释还是有更好的方法？
请记住，静态分析会产生大量误报；这是您通常为避免误报而付出的代价。也就是说，他们认为您宁愿被错误地告知某些事情看起来可疑（误报），而不是被告知实际上有问题的事情完全没问题（误报）。
所以一般来说，您应该配置这些工具，而不是接受开箱即用的默认设置，因为这会产生很多噪音。
你尝试修复所有这些吗？
在我拥有技术控制权的项目中，我的标准工作方式是鼓励人们审查我们 CI 系统中所有新的静态分析缺陷的文化。如果我们拒绝在一段时间内修复足够多的特定类型的缺陷，我们就会禁用该规则，因为它只是噪音。每隔一段时间，我们就会查看禁用的规则以确保它们仍然相关。
但是一旦我们关闭了不太有效的规则，是的，我们修复了所有的缺陷。如果您认为某事有问题，则在优先级不超过您必须做的其他事情的情况下，您应该解决它。忽略它会损害您团队的文化并发出错误的信息。
如果你忽略或禁用规则，你会记录这些吗？
规则文件是我们项目的一部分，因此提交消息足以记录在此提交中禁用了某某规则的事实。
您的经理对“留下数千个低优先级问题未解决”有何看法？
没有。我们确保他们了解我们在做什么以及为什么这样做，但他们通常（理所当然地）专注于更高级别的指标，例如速度和整体项目健康状况。
您的经理对“留下数千个低优先级问题未解决”有何看法？
我希望管理者优先考虑：决定（或被告知）任何任务是高优先级还是低优先级，并对人们将时间花在高优先级而不是低优先级任务上感到满意。
如果你看一下你的错误跟踪数据库的类比，就会发现很多报告的都是低优先级的错误，你可能永远也不会遇到。当然，它们是真正的错误，您想修复它们，但大多数程序员在非常现实的限制下工作，没有时间解决所有问题。我最近写了一篇关于静态分析缺陷的特殊性的文章。
不过，解决静态分析错误的一个重要区别是，它们通常比定期报告的错误更容易处理。因此，快速扫描缺陷不仅可以识别要修复的高优先级项目，还可以识别最容易修复的项目。毕竟，静态分析缺陷在开发过程的早期就被检测到，并且有问题的代码的特定部分被非常清楚地说明了。因此，您可能会在较低优先级的问题上获得不少低悬的果实。
我见过的使这项工作成功的各种策略包括： * 首先，确保对分析进行了适当的调整。静态分析采用出厂设置“开箱即用”，不可能理解所有代码。如果您不能自己调整它，请获得一些帮助（免责声明，我们提供一些此类帮助）。您将降低误报率并找到更多好的错误。* 识别大部分优先考虑缺陷的特征（它们可以是特定类别、特定代码区域、静态分析工具提供的内置优先级评分等）。* 确定什么水平的阈值是重要的，并可能将其作为验收标准（例如
底线：选择重点关注的内容，审查必要的内容，除非您的业务需求使您无法解决所有问题，否则不要解决所有问题
确定您希望在公司遵循的规则并禁用其余规则。您可以使用这些工具设置的许多规则都是主观风格问题，可以放心地忽略。你应该在公司风格指南中记录你曾经遵循的规则（这样你的代码就不会被这些信息弄得一团糟）。
我不会仅仅根据静态分析工具的建议对旧代码进行更改。该代码已经过测试并且可能可以正常工作。如果我需要进入代码并出于任何其他原因进行更改，那么我将运行分析并进行建议的任何更改。
我心中的关键是，即使您最终决定不修复它们，也至少要审查所有问题。原因是虫子喜欢痛苦，喜欢陪伴。我数不清有多少次我发现了 findbugs 没有报告的各种讨厌的错误；但通过查看它确实报告的看似不重要的内容找到了它们。
我个人认为代码分析虽然有用但被高估了。
我不能说 Java，但对于 C#，还有代码分析之类的东西。我同意它给了你很多聪明的想法，让你把事情做得更好，但有时这些建议很烦人。有些建议不是基于常识，而只是风格问题。在玩了一段时间的代码分析之后，我停止了使用它。原因是我碰巧不同意许多警告并且不想遵循这些建议。
一般来说，我会建议按照代码分析所说的去做。但到了一定程度。无论编写规则定义的人似乎是个人风格问题，都可以很容易地被忽略。您可以为规则 1 添加例外，然后是 2，然后是三个……直到它变老。然后，您只需停用该功能。