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

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

![0975_Objection_Handling_ru/image1.png](https://import.viva64.com/docx/blog/0975_Objection_Handling_ru/image1.png)

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

## Дорого стоит

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

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

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

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

Лучший вариант — запустить анализатор на коде проекта и посмотреть, какие проблемы он сможет найти\. Загрузить пробную версию можно [здесь](https://pvs-studio.ru/ru/pvs-studio/try-free/)\.

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

* "[PVS\-Studio ROI](https://pvs-studio.ru/ru/blog/posts/0606/)": описали, какую пользу в деньгах можно получить при использовании PVS\-Studio в проекте;
* "[Место SAST в Secure SDLC](https://pvs-studio.ru/ru/blog/posts/0937/)": рассуждаем о том, зачем нужны SAST\-решения, как они помогают снижать финансовые и репутационные риски;
* "[Философия статического анализа кода: у нас 100 программистов, анализатор нашёл мало ошибок, он бесполезен?](https://pvs-studio.ru/ru/blog/posts/0534/)": зачем использовать анализатор регулярно и почему разовая проверка может не показать пользы от инструмента\.

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

* \.NET;
* Android;
* Telegram;
* Chromium;
* Unreal Engine;
* Unity;
* \.\.\. 

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

Полный список проверенных проектов доступен [здесь](https://pvs-studio.ru/ru/blog/inspections/)\. Там же перечислены ссылки на статьи, где описываются найденные проблемы\.

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

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

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

[Эта страница](https://pvs-studio.ru/ru/pvs-studio/try-free/) поможет пройти по описанным шагам\.

Выбрать лучшие предупреждения из полученных можно с помощью [специального фильтра](https://pvs-studio.ru/ru/docs/manual/6532/)\. Если для вашего окружения этот фильтр недоступен, просмотр предупреждений рекомендую начать с уровня 'High'\.

В [документации](https://pvs-studio.ru/ru/docs/) описаны сценарии использования с разными IDE, CI/CD, а также возможности настройки анализатора\. Когда речь дойдёт до внедрения PVS\-Studio в процессы разработки, прочитайте статью "[Как внедрить статический анализатор кода в legacy проект и не демотивировать команду](https://pvs-studio.ru/ru/blog/posts/0743/)"\.

Возникли вопросы? [Пишите нам](https://pvs-studio.ru/ru/about-feedback/)\. Поможем запустить анализ и разобраться с возможными сложностями\.

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

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

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

Нужно:

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

При внедрении анализатора [выполните baselining](https://pvs-studio.ru/ru/docs/manual/0032/)\. Вот что это даст:

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

Также рекомендую прочитать статью "[Как внедрить статический анализатор кода в legacy проект и не демотивировать команду](https://pvs-studio.ru/ru/blog/posts/0743/)"\.

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

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

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

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

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

О том, как исключать файлы и директории из анализа, можно прочитать [здесь](https://pvs-studio.ru/ru/docs/manual/6640/)\.

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

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

Поэтому:

* убедитесь, что работаете только с теми группами диагностик, которые актуальны для проекта\. Например, если не нужны правила MISRA, проверьте, что диагностики этой группы выключены;
* даже в рамках нужной группы могут быть диагностики, которые неактуальны для проекта\. Например, вы проверяете C\# код и вам неважно, сравниваются вещественные числа напрямую или с учётом погрешности\. В таком случае стоит отключить соответствующую диагностику \([V3024](https://pvs-studio.ru/ru/docs/warnings/v3024/)\), чтобы уменьшить количество предупреждений\.

В [документации](https://pvs-studio.ru/ru/docs/) для конкретных IDE и платформ мы описали, как отключать диагностики и их группы\. 

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

Иногда статические анализаторы выдают предупреждения на корректный код\. Такие предупреждения называются ложноположительными \(false positives\)\. 

Для борьбы с ними в PVS\-Studio есть разные механизмы\. С их помощью можно подавлять как отдельные предупреждения, так и выполнять подавление по шаблону\. Как именно это делать, мы описали в [документации](https://pvs-studio.ru/ru/docs/manual/0017/)\.

Однако полезно понимать, какими бывают false positives и из\-за чего они могут возникать\. 

### Ошибка в логике анализатора

Рассмотрим пример:

```cpp
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 ошибся и выдал ложное предупреждение, так как не понял логики кода\.

Если вы столкнулись с подобной ситуацией, [напишите нам](https://pvs-studio.ru/ru/about-feedback/)\. Мы постараемся доработать анализатор, чтобы в будущем он не выдавал предупреждений на подобный код\.

### Анализатор прав, но предупреждение ложное

Есть другой тип false positives\. Рассмотрим пример:

```cpp
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_, эти вызовы будут для него одинаковы\. Поэтому в обоих случаях он выдаст предупреждение\.

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

```cpp
 //-V:SpecialMethod:3062
```

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

В [документации](https://pvs-studio.ru/ru/docs/manual/0017/) мы описали способы подавления предупреждений\.

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

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

Если кажется, что анализатор работает слишком долго и вы столкнулись с зависанием или чем\-то подобным — [пишите нам](https://pvs-studio.ru/ru/about-feedback/), будем разбираться\.

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

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

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

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

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

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

Подробнее об этом режиме написано в [документации](https://pvs-studio.ru/ru/docs/manual/0024/)\.

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

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

Подробнее этот режим анализа описан в [документации](https://pvs-studio.ru/ru/docs/manual/0055/)\.

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

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

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

В [этой статье](https://pvs-studio.ru/ru/blog/posts/cpp/0826/) на примере Unreal Tournament рассказали, как меняется время анализа проекта с использованием Incredibuild и без него\.

В [документации](https://pvs-studio.ru/ru/docs/manual/0041/) описали, как настроить распределённый анализ\.

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

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

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

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

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

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

Чем позже нашли проблему, тем сложнее и дороже её исправить\. Это особенно актуально для дефектов безопасности\. Относительная стоимость исправления проблемы на разных этапах жизненного цикла ПО, по [данным](https://www.researchgate.net/publication/255965523_Integrating_Software_Assurance_into_the_Software_Development_Life_Cycle_SDLC) IBM System Science Institute, выглядит так:

![0975_Objection_Handling_ru/image2.png](https://import.viva64.com/docx/blog/0975_Objection_Handling_ru/image2.png)

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

Регулярное проведение статического анализа позволяет следовать принципу shift\-left, находить проблемы раньше и таким образом уменьшать стоимость разработки\. Подробнее эта тема разбирается [здесь](https://pvs-studio.ru/ru/blog/posts/0937/)\.

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

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

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

Если непонятно, в чём дело, — [пишите нам](https://pvs-studio.ru/ru/about-feedback/), будем разбираться\.

Если хотите попробовать анализатор на синтетическом тесте, рекомендую предварительно прочитать эту статью: "[Почему я не люблю синтетические тесты](https://pvs-studio.ru/ru/blog/posts/cpp/0471/)"\. И помните, что часто реальные ошибки достаточно просты\. Пример — опечатки из проектов на C\+\+ \([ссылка](https://pvs-studio.ru/ru/blog/examples/v501/)\) и C\# \([ссылка](https://pvs-studio.ru/ru/blog/examples/v3001/)\)\. 

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

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

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

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

* проведите baseline\. Так вы будете работать только с новыми предупреждениями, не отвлекаясь на legacy;
* выполните предварительную настройку анализатора\. Исключите из анализа ненужные файлы, отключите неактуальные диагностики и т\.п\. Это снизит количество лишних предупреждений;
* установите анализатор на машины разработчиков\. Так они смогут находить и исправлять проблемы ещё легче и быстрее;
* регулярно анализируйте проект в CI и своевременно исправляйте найденные проблемы;
* настройте рассылку результатов анализа\. Менеджерам это позволит следить за качеством проекта; разработчикам — узнавать о предупреждениях, которые они могли пропустить\. Подробнее [здесь](https://pvs-studio.ru/ru/docs/manual/0050/)\.

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

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

Эта статья рассчитана на обновление и дополнение\. Если не нашли ответа на вопрос, который вас интересует, — [пишите нам](https://pvs-studio.ru/ru/about-feedback/)\! :\)