Хочу использовать в своей команде PVS-Studio. Начальник против. Как его убедить?
- Дорого стоит
- Сложно попробовать или внедрить
- Выдаёт много предупреждений
- Анализатор ошибается и не понимает логики кода (false positives)
- Анализатор работает долго и будет замедлять процессы
- Нужно загружать исходники на сторонние сервера
- Зачем проводить анализ регулярно? Можно ведь запускать только перед релизом или раз в год
- 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 и своевременно исправляйте найденные проблемы;
- настройте рассылку результатов анализа. Менеджерам это позволит следить за качеством проекта; разработчикам – узнавать о предупреждениях, которые они могли пропустить. Подробнее здесь.
Если инструмент грамотно внедрён в процесс и приносит пользу, то и вопросов о его использовании не стоит.
Я не нашёл ответа на нужный вопрос
Эта статья рассчитана на обновление и дополнение. Если не нашли ответа на вопрос, который вас интересует, – пишите нам! :)