Хочу использовать в своей команде PVS-Studio. Начальник против. Как его убедить?

• Дорого стоит
• Сложно попробовать или внедрить
• Выдаёт много предупреждений
  • При первом запуске
  • На сторонний код
  • Срабатывают неактуальные для проекта диагностики
• Анализатор ошибается и не понимает логики кода (false positives)
  • Ошибка в логике анализатора
  • Анализатор прав, но предупреждение ложное
• Анализатор работает долго и будет замедлять процессы
  • Выключение неактуальных диагностик
  • Анализ кода, изменённого с момента последней сборки (инкрементальный анализ)
  • Анализ коммитов / pull requests / merge requests
  • Распределённый анализ с использованием Incredibuild
• Нужно загружать исходники на сторонние сервера
• Зачем проводить анализ регулярно? Можно ведь запускать только перед релизом или раз в год
• PVS-Studio не находит какую-то ошибку
• Разработчики не будут пользоваться
• Я не нашёл ответа на нужный вопрос

Вы решили внедрить PVS-Studio в свой проект. Но внезапно оказывается, что начальник против, потому что... Кстати, а почему он может быть против? Давайте попробуем разобраться и понять, как можно работать с потенциальными возражениями.

Статья специально разбита на разделы: можете не читать её целиком, а изучить только волнующую вас тему.

Дорого стоит

Точно ли дело в цене?

Прежде всего нужно понять – действительно ли дело в цене? Возможно, за этим скрываются другие опасения: в замедлении процессов разработки, сложности интеграции или ещё какие-то? Если это так, то и отрабатывать нужно другие возражения.

Какую пользу принесёт PVS-Studio?

Чтобы обосновать цену, нужно понимать, какую пользу принесёт PVS-Studio.

Лучший вариант – запустить анализатор на коде проекта и посмотреть, какие проблемы он сможет найти. Загрузить пробную версию можно здесь.

Также рекомендую прочитать следующие статьи:

• "PVS-Studio ROI": описали, какую пользу в деньгах можно получить при использовании PVS-Studio в проекте;
• "Место SAST в Secure SDLC": рассуждаем о том, зачем нужны SAST-решения, как они помогают снижать финансовые и репутационные риски;
• "Философия статического анализа кода: у нас 100 программистов, анализатор нашёл мало ошибок, он бесполезен?": зачем использовать анализатор регулярно и почему разовая проверка может не показать пользы от инструмента.

Расскажите, в каких проектах PVS-Studio уже нашёл ошибки. Среди них:

• .NET;
• Android;
• Telegram;
• Chromium;
• Unreal Engine;
• Unity;
• ...

Эти проекты разрабатываются профессионалами, что не мешает PVS-Studio находить ошибки в их коде.

Полный список проверенных проектов доступен здесь. Там же перечислены ссылки на статьи, где описываются найденные проблемы.

Сложно попробовать или внедрить

Как раз наоборот. Чтобы попробовать анализатор на проекте, нужно:

• получить триальный ключ;
• загрузить дистрибутив;
• провести анализ.

Эта страница поможет пройти по описанным шагам.

Выбрать лучшие предупреждения из полученных можно с помощью специального фильтра. Если для вашего окружения этот фильтр недоступен, просмотр предупреждений рекомендую начать с уровня 'High'.

В документации описаны сценарии использования с разными IDE, CI/CD, а также возможности настройки анализатора. Когда речь дойдёт до внедрения PVS-Studio в процессы разработки, прочитайте статью "Как внедрить статический анализатор кода в legacy проект и не демотивировать команду".

Возникли вопросы? Пишите нам. Поможем запустить анализ и разобраться с возможными сложностями.

Выдаёт много предупреждений

При первом запуске

PVS-Studio выдал много предупреждений при первом запуске? Это нормально, особенно для проектов с большим объёмом legacy-кода.

Нужно:

• Осознать, что со всеми этими предупреждениями код всё же работает.
• Принять их как технический долг.
• Не допускать появления новых предупреждений, своевременно их исправлять.

При внедрении анализатора выполните baselining. Вот что это даст:

• Все предупреждения, найденные в коде проекта, скрыты. Считаем их техническим долгом.
• Команда будет видеть только те предупреждения, которые найдены в новом или изменённом коде. Так она сможет вовремя исправлять найденные проблемы.
• К скрытым предупреждениям можно вернуться позже.

Также рекомендую прочитать статью "Как внедрить статический анализатор кода в legacy проект и не демотивировать команду".

Примечание. Если вы анализируете код на дефекты безопасности, перед подавлением всех предупреждений рекомендую просмотреть наиболее критичные из них (уровень "High").

На сторонний код

Один из этапов настройки анализатора – исключение из проверки стороннего кода, который вы не планируете править:

• автоматически сгенерированные файлы;
• тесты;
• код сторонних библиотек.

Исключение из анализа подобного кода не только уменьшит количество предупреждений, но и сократит время работы анализатора.

О том, как исключать файлы и директории из анализа, можно прочитать здесь.

Срабатывают неактуальные для проекта диагностики

Анализатор находит дефекты разных типов. Однако не все из них будут актуальны для проекта.

Поэтому:

• убедитесь, что работаете только с теми группами диагностик, которые актуальны для проекта. Например, если не нужны правила MISRA, проверьте, что диагностики этой группы выключены;
• даже в рамках нужной группы могут быть диагностики, которые неактуальны для проекта. Например, вы проверяете C# код и вам неважно, сравниваются вещественные числа напрямую или с учётом погрешности. В таком случае стоит отключить соответствующую диагностику (V3024), чтобы уменьшить количество предупреждений.

В документации для конкретных IDE и платформ мы описали, как отключать диагностики и их группы.

Анализатор ошибается и не понимает логики кода (false positives)

Иногда статические анализаторы выдают предупреждения на корректный код. Такие предупреждения называются ложноположительными (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 предупреждения:

• V3062. An object 'obj' is used as an argument to its own method. Consider checking the first actual argument of the 'SpecialMethod' method.
• V3062. An object 'anotherObj' is used as an argument to its own method. Consider checking the first actual argument of the 'AnotherMethod' method.

Методы SpecialMethod и AnotherMethod специфичны для проекта. SpecialMethod может принимать в качестве аргумента тот же объект, у которого сам метод вызван, а AnotherMethod – нет.

Получается, что во втором случае анализатор выдал правильное предупреждение, а в первом — ошибся. Если PVS-Studio ничего не знает о SpecialMethod и AnotherMethod, эти вызовы будут для него одинаковы. Поэтому в обоих случаях он выдаст предупреждение.

Если это единичный случай, то можно подавить конкретное предупреждение. Если подобный код встречается регулярно, лучше подавить предупреждение по шаблону:

 //-V:SpecialMethod:3062

В таком случае анализатор не будет выдавать предупреждение на вызовы методов вида obj.SpecialMethod(obj).

В документации мы описали способы подавления предупреждений.

Анализатор работает долго и будет замедлять процессы

Время анализа зависит от ресурсов машины, на которой запущен PVS-Studio, объёма и сложности кодовой базы.

Если кажется, что анализатор работает слишком долго и вы столкнулись с зависанием или чем-то подобным – пишите нам, будем разбираться.

Если вы просто хотите сократить время анализа, попробуйте следующее:

• отключите неактуальные группы диагностик;
• исключите файлы и директории с кодом, который не будете править, из анализа;
• используйте инкрементальный анализ, чтобы проверять только новый или изменённый код;
• настройте анализ коммитов / pull requests / merge requests;
• анализируйте код параллельно на нескольких машинах с помощью систем распределённой сборки.

Выключение неактуальных диагностик

Зачем это может понадобиться и как это сделать, мы разобрали выше в разделе "Выдаёт много предупреждений: срабатывают неактуальные для проекта диагностики".

Анализ кода, изменённого с момента последней сборки (инкрементальный анализ)

Инкрементальный анализ позволяет проверять только те файлы, которые изменились с момента последней сборки. Это ещё один способ анализировать только новый или изменённый код.

Подробнее об этом режиме написано в документации.

Анализ коммитов / pull requests / merge requests

PVS-Studio можно настроить на проверку отдельных коммитов / PR / MR, а не всего проекта целиком. Это сократит время анализа и поможет находить проблемы раньше.

Подробнее этот режим анализа описан в документации.

Примечание. Вместе с частичным анализом рекомендую регулярно проводить анализ проекта целиком. Например, во время ночных тестов.

Распределённый анализ с использованием Incredibuild

Использование PVS-Studio с системами распределённой сборки позволяет выполнять анализ одновременно на нескольких машинах. Так можно существенно снизить время анализа.

В этой статье на примере Unreal Tournament рассказали, как меняется время анализа проекта с использованием Incredibuild и без него.

В документации описали, как настроить распределённый анализ.

Примечание. На данный момент PVS-Studio и Incredibuild можно использовать только для анализа C и C++ проекты.

Нужно загружать исходники на сторонние сервера

На самом деле нет, загружать код на сторонние сервера не нужно. PVS-Studio – on-premises решение. Вы можете сами выбирать, где проводить анализ:

• на машинах разработчиков;
• на локальном сервере;
• в облаке, которое выбрали самостоятельно.

При необходимости работать с анализатором можно полностью в режиме offline.

Зачем проводить анализ регулярно? Можно ведь запускать только перед релизом или раз в год

Чем позже нашли проблему, тем сложнее и дороже её исправить. Это особенно актуально для дефектов безопасности. Относительная стоимость исправления проблемы на разных этапах жизненного цикла ПО, по данным IBM System Science Institute, выглядит так:

Из графика видно, что после релиза исправление уязвимости обходится в 15 раз дороже, чем во время разработки, и в 100 раз дороже, чем на этапе проектирования.

Регулярное проведение статического анализа позволяет следовать принципу shift-left, находить проблемы раньше и таким образом уменьшать стоимость разработки. Подробнее эта тема разбирается здесь.

PVS-Studio не находит какую-то ошибку

Причин, по которым не находится ошибка, может быть несколько:

• эта функциональность не реализована в анализаторе;
• диагностика, которая ищет эту проблему, выключена;
• директория с анализируемым кодом исключена из анализа;
• ...

Если непонятно, в чём дело, – пишите нам, будем разбираться.

Если хотите попробовать анализатор на синтетическом тесте, рекомендую предварительно прочитать эту статью: "Почему я не люблю синтетические тесты". И помните, что часто реальные ошибки достаточно просты. Пример – опечатки из проектов на C++ (ссылка) и C# (ссылка).

Разработчики не будут пользоваться

Статический анализатор нужно внедрить в процесс разработки так, чтобы:

• все понимали, какую пользу он приносит;
• анализатор упрощал жизнь, а не усложнял её.

Конкретный совет по внедрению здесь дать сложно: многое зависит от того, как выстроены процессы в команде. Общие рекомендации могут быть такими:

• проведите baseline. Так вы будете работать только с новыми предупреждениями, не отвлекаясь на legacy;
• выполните предварительную настройку анализатора. Исключите из анализа ненужные файлы, отключите неактуальные диагностики и т.п. Это снизит количество лишних предупреждений;
• установите анализатор на машины разработчиков. Так они смогут находить и исправлять проблемы ещё легче и быстрее;
• регулярно анализируйте проект в CI и своевременно исправляйте найденные проблемы;
• настройте рассылку результатов анализа. Менеджерам это позволит следить за качеством проекта; разработчикам – узнавать о предупреждениях, которые они могли пропустить. Подробнее здесь.

Если инструмент грамотно внедрён в процесс и приносит пользу, то и вопросов о его использовании не стоит.

Я не нашёл ответа на нужный вопрос

Эта статья рассчитана на обновление и дополнение. Если не нашли ответа на вопрос, который вас интересует, – пишите нам! :)