metrica
Мы используем куки, чтобы пользоваться сайтом было удобно.
Хорошо
to the top
close form

Заполните форму в два простых шага ниже:

Ваши контактные данные:

Шаг 1
Поздравляем! У вас есть промокод!

Тип желаемой лицензии:

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

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

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

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

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

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


Если вы так и не получили ответ, пожалуйста, проверьте папку
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 и своевременно исправляйте найденные проблемы;
  • настройте рассылку результатов анализа. Менеджерам это позволит следить за качеством проекта; разработчикам – узнавать о предупреждениях, которые они могли пропустить. Подробнее здесь.

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

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

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

Популярные статьи по теме


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

Следующие комментарии next comments
close comment form