Вы решили внедрить PVS-Studio в свой проект. Но внезапно оказывается, что начальник против, потому что... Кстати, а почему он может быть против? Давайте попробуем разобраться и понять, как можно работать с потенциальными возражениями.
Статья специально разбита на разделы: можете не читать её целиком, а изучить только волнующую вас тему.
Точно ли дело в цене?
Прежде всего нужно понять – действительно ли дело в цене? Возможно, за этим скрываются другие опасения: в замедлении процессов разработки, сложности интеграции или ещё какие-то? Если это так, то и отрабатывать нужно другие возражения.
Какую пользу принесёт PVS-Studio?
Чтобы обосновать цену, нужно понимать, какую пользу принесёт PVS-Studio.
Лучший вариант – запустить анализатор на коде проекта и посмотреть, какие проблемы он сможет найти. Загрузить пробную версию можно здесь.
Также рекомендую прочитать следующие статьи:
Расскажите, в каких проектах PVS-Studio уже нашёл ошибки. Среди них:
Эти проекты разрабатываются профессионалами, что не мешает PVS-Studio находить ошибки в их коде.
Полный список проверенных проектов доступен здесь. Там же перечислены ссылки на статьи, где описываются найденные проблемы.
Как раз наоборот. Чтобы попробовать анализатор на проекте, нужно:
Эта страница поможет пройти по описанным шагам.
Выбрать лучшие предупреждения из полученных можно с помощью специального фильтра. Если для вашего окружения этот фильтр недоступен, просмотр предупреждений рекомендую начать с уровня 'High'.
В документации описаны сценарии использования с разными IDE, CI/CD, а также возможности настройки анализатора. Когда речь дойдёт до внедрения PVS-Studio в процессы разработки, прочитайте статью "Как внедрить статический анализатор кода в legacy проект и не демотивировать команду".
Возникли вопросы? Пишите нам. Поможем запустить анализ и разобраться с возможными сложностями.
PVS-Studio выдал много предупреждений при первом запуске? Это нормально, особенно для проектов с большим объёмом legacy-кода.
Нужно:
При внедрении анализатора выполните baselining. Вот что это даст:
Также рекомендую прочитать статью "Как внедрить статический анализатор кода в legacy проект и не демотивировать команду".
Примечание. Если вы анализируете код на дефекты безопасности, перед подавлением всех предупреждений рекомендую просмотреть наиболее критичные из них (уровень "High").
Один из этапов настройки анализатора – исключение из проверки стороннего кода, который вы не планируете править:
Исключение из анализа подобного кода не только уменьшит количество предупреждений, но и сократит время работы анализатора.
О том, как исключать файлы и директории из анализа, можно прочитать здесь.
Анализатор находит дефекты разных типов. Однако не все из них будут актуальны для проекта.
Поэтому:
В документации для конкретных IDE и платформ мы описали, как отключать диагностики и их группы.
Иногда статические анализаторы выдают предупреждения на корректный код. Такие предупреждения называются ложноположительными (false positives).
Для борьбы с ними в PVS-Studio есть разные механизмы. С их помощью можно подавлять как отдельные предупреждения, так и выполнять подавление по шаблону. Как именно это делать, мы описали в документации.
Однако полезно понимать, какими бывают false positives и из-за чего они могут возникать.
Рассмотрим пример:
Thread thread = new Thread(threadStartDeleagate);
thread.UnsafeStart();Предупреждение анализатора может быть таким: V3082. The 'Thread' object 'thread' is created but is not started. It is possible that a call to 'Start' method is missing.
PVS-Studio ошибся и выдал ложное предупреждение, так как не понял логики кода.
Если вы столкнулись с подобной ситуацией, напишите нам. Мы постараемся доработать анализатор, чтобы в будущем он не выдавал предупреждений на подобный код.
Есть другой тип false positives. Рассмотрим пример:
obj.SpecialMethod(obj);
anotherObj.AnotherMethod(anotherObj);Допустим, анализатор выдал 2 предупреждения:
Методы SpecialMethod и AnotherMethod специфичны для проекта. SpecialMethod может принимать в качестве аргумента тот же объект, у которого сам метод вызван, а AnotherMethod – нет.
Получается, что во втором случае анализатор выдал правильное предупреждение, а в первом — ошибся. Если PVS-Studio ничего не знает о SpecialMethod и AnotherMethod, эти вызовы будут для него одинаковы. Поэтому в обоих случаях он выдаст предупреждение.
Если это единичный случай, то можно подавить конкретное предупреждение. Если подобный код встречается регулярно, лучше подавить предупреждение по шаблону:
//-V:SpecialMethod:3062В таком случае анализатор не будет выдавать предупреждение на вызовы методов вида obj.SpecialMethod(obj).
В документации мы описали способы подавления предупреждений.
Время анализа зависит от ресурсов машины, на которой запущен PVS-Studio, объёма и сложности кодовой базы.
Если кажется, что анализатор работает слишком долго и вы столкнулись с зависанием или чем-то подобным – пишите нам, будем разбираться.
Если вы просто хотите сократить время анализа, попробуйте следующее:
Зачем это может понадобиться и как это сделать, мы разобрали выше в разделе "Выдаёт много предупреждений: срабатывают неактуальные для проекта диагностики".
Инкрементальный анализ позволяет проверять только те файлы, которые изменились с момента последней сборки. Это ещё один способ анализировать только новый или изменённый код.
Подробнее об этом режиме написано в документации.
PVS-Studio можно настроить на проверку отдельных коммитов / PR / MR, а не всего проекта целиком. Это сократит время анализа и поможет находить проблемы раньше.
Подробнее этот режим анализа описан в документации.
Примечание. Вместе с частичным анализом рекомендую регулярно проводить анализ проекта целиком. Например, во время ночных тестов.
Использование PVS-Studio с системами распределённой сборки позволяет выполнять анализ одновременно на нескольких машинах. Так можно существенно снизить время анализа.
В этой статье на примере Unreal Tournament рассказали, как меняется время анализа проекта с использованием Incredibuild и без него.
В документации описали, как настроить распределённый анализ.
Примечание. На данный момент PVS-Studio и Incredibuild можно использовать только для анализа C и C++ проекты.
На самом деле нет, загружать код на сторонние сервера не нужно. PVS-Studio – on-premises решение. Вы можете сами выбирать, где проводить анализ:
При необходимости работать с анализатором можно полностью в режиме offline.
Чем позже нашли проблему, тем сложнее и дороже её исправить. Это особенно актуально для дефектов безопасности. Относительная стоимость исправления проблемы на разных этапах жизненного цикла ПО, по данным IBM System Science Institute, выглядит так:
Из графика видно, что после релиза исправление уязвимости обходится в 15 раз дороже, чем во время разработки, и в 100 раз дороже, чем на этапе проектирования.
Регулярное проведение статического анализа позволяет следовать принципу shift-left, находить проблемы раньше и таким образом уменьшать стоимость разработки. Подробнее эта тема разбирается здесь.
Причин, по которым не находится ошибка, может быть несколько:
Если непонятно, в чём дело, – пишите нам, будем разбираться.
Если хотите попробовать анализатор на синтетическом тесте, рекомендую предварительно прочитать эту статью: "Почему я не люблю синтетические тесты". И помните, что часто реальные ошибки достаточно просты. Пример – опечатки из проектов на C++ (ссылка) и C# (ссылка).
Статический анализатор нужно внедрить в процесс разработки так, чтобы:
Конкретный совет по внедрению здесь дать сложно: многое зависит от того, как выстроены процессы в команде. Общие рекомендации могут быть такими:
Если инструмент грамотно внедрён в процесс и приносит пользу, то и вопросов о его использовании не стоит.
Эта статья рассчитана на обновление и дополнение. Если не нашли ответа на вопрос, который вас интересует, – пишите нам! :)