处理异议:静态分析将占用部分工作时间

虫子 在会议上与人们交谈以及在文章评论中,我们面临以下反对意见:静态分析减少了检测错误的时间,但占用了程序员的时间,这抵消了使用它的好处,甚至减慢了开发过程。 让我们弄清楚这个异议,并尝试证明它是毫无根据的。

从上下文中删除“静态分析将占用一部分工作时间”这一说法是正确的。 定期检查针对新代码或修改代码发出的分析器警告肯定需要一些时间。 但是,我们应该继续这个想法:但是花费的时间比通过其他方法发现错误所需的时间少得多。 找出来自用户的错误甚至更糟。

单元测试在这里可以是一个很好的类比。 单元测试也需要开发人员花费时间,但这不是不使用它们的原因。 使用单元测试时,质量更好的安全代码的好处胜于编写它们的成本。

另一个比喻:编译器警告。 这通常是一个非常接近的主题,因为在某种程度上可以将静态分析工具的警告视为编译器警告的扩展。 自然,当程序员看到编译器警告时,会花一些时间来处理它。 他必须更改代码或花费一些时间来抑制警告,例如使用#pragma。 但是,这种时间承诺从来不是禁用编译器警告的原因。 如果有人这样做,那么它将被其他人明确地解释为职业不适合。

但是,担心浪费时间来警告静态代码分析器的原因何在?

答案很简单。 尚不熟悉这种方法的程序员会混淆试运行和常规用法。 第一次运行时,任何分析器都会给出大量警告,甚至看上去很恐怖。 原因是尚未配置分析仪。 而配置的分析仪会发出少量经常使用的误报。 换句话说,大多数警告指示真正的缺陷或代码气味。 进行此配置很重要。 这是把静态分析仪从浪费时间的邪恶变成朋友和助手的窍门。

任何静态分析仪都会首先发出许多误报。 造成这种情况的原因很多,本主题值得另写一篇文章。 自然,其他分析仪的开发人员和我们的团队都在与误报斗争。 但是,如果您只是第一次在项目上运行分析仪,仍然会有很多警告。 顺便说一句,编译器警告也是如此。 假设您有一个大型项目,例如,使用Visual C ++编译器一直在构建它。 可以说,该项目奇迹般地可移植并使用GCC进行了编译。 即使这样,您也会收到来自GCC的一系列警告。 在大型项目中经历过编译器变更的人们都知道我在说什么。

警告

但是,没有人会强迫您在更改编译器或运行分析器后不断挖掘警告。 显而易见的下一步是设置编译器或分析器。 那些说“警告分析很耗时”的人评估了使用该工具的复杂性,只考虑一开始就需要克服的所有这些警告,而没有考虑轻松地常规使用。

设置分析器和编译器并不像程序员希望爬出来那样困难和费力。 如果您是经理,请不要听他们的话。 他们只是懒惰。 程序员可以自豪地说出自己是如何搜索测试人员/客户端3天的错误的。 这对他很好。 但是,从他的角度来看,花一天的时间安装该工具是不可接受的,在此之后,将在将该错误导入版本控制系统之前将其检测出来。

是的,设置后会出现误报。 但是他们的人数被夸大了。 设置分析仪很有可能使误报的百分比为10%-15%。 也就是说,对于发现的9个缺陷,只有1个警告将被抑制为错误警告。 那么“浪费时间”在哪里呢? 同时,15%是非常真实的价值; 您可以在本文中阅读有关它的更多信息。

还有一件事。 程序员可能会反对:

好吧,假设常规的静态分析运行确实有效。 但是如何处理我第一次听到的噪音? 在我们的大型项目中,我们将无法在承诺的1天时间内安装该工具。 只是重新编译以检查下一批设置需要几个小时。 我们还没有准备好花几个星期的时间。

这不是问题,而是试图找到不引入新内容的理由。 当然,在一个大型项目中,一切总是很困难的。 但是首先,我们提供支持,并帮助将PVS-Studio集成到开发过程中。 其次,没有必要立即开始整理所有警告。

如果您的应用程序正常运行,那么那里存在的错误并不是那么严重,可能存在于很少使用的代码中。 已经发现了严重的明显错误,并已使用较慢且更昂贵的方法进行了修复。 我将在下面的注释中对此进行描述。 现在这不是很重要。 在代码中进行大量编辑,更正许多微不足道的错误是没有意义的。 如此大的重构很容易破坏某些东西,而带来的危害将大于好处。

最好考虑现有的警告技术债务。 您可以稍后再偿还债务,并逐步处理旧的警告。 通过使用批量警告抑制机制,您可以在大型项目中快速开始使用PVS-Studio。 这是正在发生的事情的简短描述:

  1. 您从分析中排除了明显多余的目录(第三方库)。 您最好在一开始就这样做,以减少分析时间。
  2. 您尝试使用PVS-Studio并调查最有趣的警告 。 您喜欢结果,然后向同事和老板展示该工具。 团队决定定期开始使用它。
  3. 该项目正在检查中。 使用质量抑制机制可以禁用所有抑制的警告。 换句话说,您此时拥有的所有警告现在都被视为技术债,可以在以后进行修订。
  4. 带有禁止警告的结果文件进入版本控制系统。 这个文件很大,但是没关系。 您只需一次(或至少很少)执行这些操作。 现在所有开发人员都将拥有此文件。
  5. 现在,所有开发人员都可以看到仅与新代码或修改后的代码有关的警告。 从那时起,团队开始从静态分析中受益。 接下来,您逐步设置分析仪并处理技术债务。


顺便说一句,用于无趣警告的存储系统非常智能。 将为可能存在错误的行以及上一行和下一行保存哈希。 结果,如果您在其中一个文件的开头添加一行,则不会误入歧途,并且分析器将对代码保持沉默,这被认为是技术债。

我希望,我能够消除关于静态分析的先入之见。 快来下载并试用我们的PVS-Studio静态代码分析器。 它会在早期阶段检测到许多错误,并使您的代码总体上更可靠,更好。

注意事项

在开发任何项目时,新错误不断出现并得到解决。 未找到的错误会在代码中“解决”很长时间,然后在应用静态代码分析时可以检测到其中的许多错误。 有时这会给人一种错误的印象,即静态分析器在很少使用的代码段中只会发现一些有趣的错误。 好吧,这是真的-如果您使用了错误的分析仪,并且仅在发行前不久(例如,不时)运行它的话。 有关此主题的更多信息,请参见此处 。 是的,我们自己在撰写文章时会对开源项目进行一次性检查。 但是我们有不同的目的。 我们专注于演示代码分析器检测缺陷的能力。 一般而言,此任务与提高项目代码的质量和减少修复错误的成本无关。

附加链接

  1. PVS-Studio的投资回报率
  2. 为什么静态分析可以改善复杂的C ++代码库
  3. 伊万·波诺马列夫(Ivan Ponomarev)。 在此过程中引入静态分析,而不仅仅是使用它来查找错误

Source: https://habr.com/ru/post/zh-CN467151/


All Articles