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

Ban*_*zen 12 java static-analysis findbugs

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

随着更严重的问题得到解决,存在大量低严重性问题.你如何处理这些低优先级的问题?

  • 你试着修理所有这些吗?
  • 或者只在新编写的代码中?
  • 你经常禁用某些规则吗?(我发现我几乎可以使用任何可用的工具).

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

Joh*_*lla 12

请记住,静态分析意味着产生大量误报; 这是您为通常避免误报所支付的价格.也就是说,他们认为你更愿意被错误地告知某些事情看起来很可疑(误报),而不是被告知事实上一个问题是完全正确的(假阴性).

因此,一般来说,您应该配置这些工具,而不是接受现成的默认设置,这会产生很多噪音.

你试着修理所有这些吗?

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

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

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

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

你的经理们对"留下几千个低优先级问题没有修复"有什么看法?

没有.我们确保他们了解我们正在做什么以及为什么,但他们通常(理所当然地)专注于更高级别的指标,如速度和整体项目健康.