Для получения триального ключа
заполните форму ниже
Team license
Enterprise license
** Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Запросите информацию о ценах
Новая лицензия
Продление лицензии
--Выберите валюту--
USD
EUR
RUB
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Бесплатная лицензия PVS-Studio для специалистов Microsoft MVP
** Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Для получения лицензии для вашего открытого
проекта заполните, пожалуйста, эту форму
** Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Мне интересно попробовать плагин на:
** Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

Ваше сообщение отправлено.

Мы ответим вам на


Если вы так и не получили ответ, пожалуйста, проверьте папку
Spam/Junk и нажмите на письме кнопку "Не спам".
Так Вы не пропустите ответы от нашей команды.

>
>
Хочу использовать в своей команде PVS-S…

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

02 Авг 2022

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

0975_Objection_Handling_ru/image1.png

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

Дорого стоит

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

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

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

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

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

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

Расскажите, в каких проектах 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, выглядит так:

0975_Objection_Handling_ru/image2.png

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Последние статьи:

Опрос:

Популярные статьи по теме
Место SAST в Secure SDLC: 3 причины внедрения в DevSecOps-пайплайн

Дата: 19 Апр 2022

Автор: Сергей Васильев

Репутационные и денежные риски, связанные с уязвимостями, огромны. На фоне этого понятен повышенный интерес к безопасности и стремление выстроить цикл безопасной разработки (SSDLC). Сегодня мы погово…
Ускоряем сборку и анализ при помощи Incredibuild

Дата: 17 Май 2021

Автор: Максим Звягинцев

"Да сколько ты ещё будешь собирать?" – фраза, которую каждый разработчик произносил хотя бы раз посреди ночи. Да, сборка бывает долгой и от этого никуда не деться. Нельзя же просто так взять и распар…
Как статический анализ кода помогает в сфере GameDev

Дата: 30 Ноя 2020

Автор: Георгий Грибков

Игровая индустрия не стоит на месте и с каждым днём развивается всё быстрее и быстрее. Вместе с ростом индустрии растёт и сложность разработки: кода становится больше и багов в нём тоже становится бо…
Статический анализ – от знакомства до интеграции

Дата: 06 Авг 2020

Автор: Максим Звягинцев

Устав от нескончаемого code review или отладки, временами задумываешься, как бы упростить себе жизнь. И немного поискав, ну или случайно наткнувшись, можно увидеть волшебное словосочетание: "Статичес…
Как внедрить статический анализатор кода в legacy проект и не демотивировать команду

Дата: 20 Июн 2020

Автор: Андрей Карпов

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

Комментарии (0)

Следующие комментарии
Unicorn with delicious cookie
Мы используем куки, чтобы пользоваться сайтом было удобно.
Хорошо