在会议上以及在文章评论中与人们进行交流时，我们遇到以下反对意见：静态分析减少了发现错误的时间，但是占用了程序员的时间，这消除了使用它的好处，甚至减慢了开发过程。 让我们分析这个反对意见，并证明它是毫无根据的。
与上下文隔离的“静态分析将占用一部分工作时间”这一说法是正确的。 定期检查针对新代码或更改代码发出的静态分析器警告确实需要时间。 但是，这种想法应该继续下去：但是花费在此上的时间比通过其他方法识别错误所花费的时间要少得多。 更糟糕的是从客户那里学习错误。
在这里，单元测试可以是一个很好的类比。 单元测试也需要开发人员花费时间，但这不是不使用它们的理由。 使用单元测试时编写更好和更可靠的代码的好处超出了编写它们的成本。
另一个比喻：编译器警告。 这通常是一个非常接近的主题，因为静态分析工具的警告可以看作是编译器警告的扩展的第一近似值。 自然，当程序员看到编译器警告时，会花时间在上面。 它应该更改代码，或显式地花费时间来抑制警告，例如，使用#pragma。 但是，这不是禁用编译器警告的原因。 如果有人这样做，那么它将被他人明确地解释为职业不合适。
但是，担心花时间警告静态代码分析器的原因何在？
一切都非常简单。 仍然不熟悉该方法的程序员会混淆测试运行和常规使用。 刚开始时，所有分析器都会给出大量警告，甚至看上去很吓人。 原因是尚未配置分析仪。 经过调谐的分析仪在常规发射期间会产生少量误报。 换句话说，大多数警告会显示出真正的缺陷或气味代码。 进行此设置非常重要。 这是将静态分析仪从费时的邪恶变成朋友和帮助者的全部技巧。
任何静态分析仪都会首先产生很多误报。 造成这种情况的原因很多，本主题值得另写一篇文章。 自然，我们和其他分析仪的开发人员都
在为误报
而苦苦挣扎 。 但是，如果您未经准备就突然在某个项目上使用并运行分析仪，那么仍然会有很多积极的方面。 顺便说一句，带有编译器警告。 假设您有一个大型项目，例如，总是使用Visual C ++编译器来构建。 假设项目奇迹般地可移植并且使用GCC进行了编译。 即使这样，您也会收到来自GCC的警告。 任何在大型项目中经历过编译器更改的人都知道这是什么。
但是，在更改编译器或启动分析器后，没有人会不断从警告中不断挖掘垃圾。 下一步自然是配置编译器或分析器。 那些说“警告分析很耗时”的人评估了工具的实施复杂性，只考虑一开始就需要克服的所有这些警告，而没有考虑平静地常规使用。
设置分析器以及编译器并不像程序员所担心的那样复杂且费力。 如果您是经理，请不要听他们的话。 他们只是懒惰。 程序员可以自豪地告诉他如何花3天的时间来查找测试人员/客户发现的错误。 这对他来说是正常的。 但是，从他的角度来看，花一天的时间调整该工具是不可接受的，此后将在将其导入版本控制系统之前检测到类似的错误。
是的，调整后会出现错误警报。 但是他们的人数被夸大了。 可以将分析仪配置为使误报的百分比为10％-15％。 即 对于发现的9个缺陷，只有1个警告将被抑制为错误。 那么“浪费时间”在哪里呢？ 同时，15％是非常真实的价值，可以在
本文中更详细地找到。
还有一件事。 程序员可能会反对：
好吧，假设定期进行静态分析确实有效。 但是如何处理初始噪声？ 在我们的大型项目中，我们将无法在承诺的1天之内配置该工具。 仅一次重新编译即可检查下一批设置，这需要几个小时。 我们还没有准备好花几个星期的时间来完成所有这些工作。这不是问题，而是试图找到不引入新内容的理由。 当然，在大型项目中，一切都不容易。 但是，首先，我们提供支持并帮助将PVS-Studio集成到开发过程中。 其次，根本没有必要开始整理所有警告。
由于您的应用程序正常工作，这意味着那里的错误不是那么严重，很可能存在于很少使用的代码中。 已经发现了严重的公开错误，并使用速度较慢且价格昂贵的方法进行了更正。 但是在下面的
注释中 。 现在，其他事情对我们很重要。 在代码中进行大量编辑，更正许多小错误是没有意义的。 如此多的重构，很容易破坏某些东西，弊大于利。
最好将现有警告视为技术债务。 以后可能还清债务，并逐步处理旧的警告。 使用
大规模警报抑制机制 ，您可以在大型项目中快速使用PVS-Studio。 很简单，它是这样的：
- 您从分析中明确排除了冗余目录（第三方库）。 无论如何，最好在开始时就进行此设置，以减少分析时间。
- 您可以尝试PVS-Studio并研究最有趣的警告 。 您喜欢结果，然后向同事和上司展示该工具。 该小组决定开始常规使用。
- 该项目正在验证中。 使用质量抑制机制禁用所有找到的警告。 换句话说，所有当前可用的警告现在都被视为技术债务，可以在以后退还。
- 带有禁止警告的结果文件将放置在版本控制系统中。 这个文件很大，但是并不可怕。 您只需执行一次此操作（或者至少很少会执行此操作）。 现在，此文件将出现在所有开发人员中。
- 现在，所有开发人员都可以看到仅适用于新代码或更改代码的警告。 从这一刻起，团队开始从静态分析中受益。 逐步设置分析仪并承担技术债务。
顺便说一句，用于存储无趣警告的系统足够智能。 存储具有潜在错误的字符串以及上一个和下一个哈希的哈希值。 因此，如果在其中一个文件的开头添加一行，则不会“腐蚀”任何内容，并且分析仪将仍然对视为技术职责的代码保持沉默。
我希望我们能够消除关于静态分析的偏见之一。 快来
下载并试用我们的PVS-Studio静态代码分析器。 它会在早期阶段检测到很多错误，并使您的代码整体上更可靠，更优质。
注意事项在开发任何项目时，都会不断出现新的错误并予以纠正。 未检测到的错误会在代码中长期存在，然后在运行静态代码分析时便会检测到许多错误。 因此，有时会产生一种错误的感觉，即静态分析器在很少使用的代码段中仅发现一些有趣的错误。 当然，如果您不正确地使用分析仪而仅不时地运行它（例如，在发行版发行前不久），就会出现这种情况。 更多关于这个话题
在这里 。 是的，在撰写文章时，我们自己对开放项目进行一次性检查。 但是我们有一个不同的目标。 我们想证明代码分析器检测缺陷的功能。 这项任务与提高整个项目代码的质量以及减少与纠错相关的成本无关。
附加链接：- PVS-Studio的投资回报率 。
- 静态分析将改善复杂的C ++项目的代码库 。
- Heisenbug2019。IvanPonomarev的报告“ 连续静态代码分析 ”。
- 伊万·波诺马列夫（Ivan Ponomarev）。 将静态分析嵌入到流程中，而不要寻找错误 。
如果您想与说英语的读者分享这篇文章，请使用以下链接：Andrey Karpov。
处理异议：静态分析将占用一部分工作时间 。