Хабрахабр

Работа с возражениями: статический анализ будет отнимать часть рабочего времени

Держи багОбщаясь с людьми на конференциях и в комментариях к статьям, мы сталкиваемся со следующим возражением: статический анализ сокращает время на нахождение ошибок, но отнимает время у программистов, что нивелирует пользу от его использования и даже наоборот тормозит процесс разработки. Давайте разберём это возражение и покажем, что оно беспочвенно.
Утверждение «статический анализ будет отнимать часть рабочего времени» в отрыве от контекста является верным. Регулярный просмотр предупреждений статического анализатора, выдаваемых на новый или изменённый код, действительно отнимает время. Однако следует продолжить мысль: но затрачиваемое на это время гораздо меньше, чем потраченное на выявление ошибок другими методами. Ещё хуже — узнавать об ошибках от клиентов.

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

Это вообще очень близкая тема, так как предупреждения инструментов статического анализа в первом приближении можно рассматривать как расширение предупреждений компиляторов. Ещё одна аналогия: предупреждения компилятора. Он должен или изменить код, или явно потратить время на подавление предупреждения, например, с помощью #pragma. Естественно, когда программист видит предупреждение компилятора, он тратит на него время. А если кто-то так сделает, это будет однозначно интерпретироваться другими как профессиональная непригодность. Однако эти затраты времени не являются причиной отключить предупреждения компилятора.

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

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

Причин тому много, и эта тема заслуживает отдельной статьи. Любой статический анализатор вначале выдаст много ложных срабатываний. Но срабатываний всё равно будет много, если без подготовки вдруг взять и запустить анализатор на каком-то проекте. Естественно, и мы, и разработчики других анализаторов борются с ложными срабатывания. Пусть у вас есть большой проект, который вы всегда собирали, например, с помощью компилятора Visual C++. Такая же картина, кстати, и с предупреждениями компилятора. Даже в этом случае вы получите гору предупреждений от GCC. Предположим, проект чудесным образом получился переносимым и скомпилировался с помощью GCC. Кто переживал смену компиляторов в большом проекте, тот понимает, о чём речь.

Предупреждения

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

Если вы — менеджер, не слушайте их. Настройка анализаторов, как и компиляторов, не так сложна и трудозатрата, как любят пугать программисты. Программист с гордостью может рассказывать, как он 3 дня искал баг, найденный тестировщиком/клиентом. Они просто ленятся. Однако с его точки зрения неприемлемо потратить один день на настройку инструмента, после чего подобная ошибка будет выявляться, ещё не попав в систему контроля версий. И это для него нормально.

Но их количество преувеличивается. Да, ложные срабатывания будут присутствовать и после настройки. Т.е. Вполне можно настроить анализатор, чтобы процент ложных срабатываний составлял 10%-15%. Так где же здесь «трата времени»? на 9 найденных дефектов только 1 предупреждение потребует подавления как ложное. При этом 15% — это вполне реальное значение, о чём подробнее можно прочитать в этой статье.

Программист может возразить: Остаётся ещё один момент.

Но что делать с первоначальным шумом? Хорошо, предположим, регулярные запуски статического анализа действительно эффективны. Только одна перекомпиляция, чтобы проверить очередную порцию настроек, занимает несколько часов. На нашем большом проекте мы не сможем настроить инструмент за 1 обещанный день. Мы не готовы потратить пару недель на всё это.

Конечно, в большом проекте всегда всё непросто. И это не проблема, а попытка найти повод не внедрять что-то новое. А во-вторых, вовсе не обязательно начинать разбирать все предупреждения. Но, во-первых, мы оказываем поддержку и помогаем интегрировать PVS-Studio в процесс разработки.

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

К долгу можно будет вернуться позже и работать со старыми предупреждениями постепенно. Лучше считать существующие предупреждения техническим долгом. Совсем кратко это происходит так: Используя механизм массового подавления предупреждений, вы можете начать быстро использовать PVS-Studio в большом проекте.

  1. Вы исключаете из анализа явно лишние директории (сторонние библиотеки). Эту настройку лучше в любом случае делать в самом начале, чтобы сократить время анализа.
  2. Вы пробуете PVS-Studio и изучаете самые интересные предупреждения. Вам нравятся результаты, и вы показываете инструмент коллегам и начальству. Команда решает начать его регулярное использование.
  3. Проверяется проект. Все найденные предупреждения отключаются с помощью механизма массового подавления. Другими словами, все имеющиеся на данный момент предупреждения теперь считаются техническим долгом, к которому можно вернуться позже.
  4. Получившийся файл с подавленными предупреждениями закладывается в систему контроля версий. Этот файл большой, но это не страшно. Вы делаете эту операцию один раз (или, по крайней мере, будете делать крайне редко). И теперь этот файл появится у всех разработчиков.
  5. Теперь все разработчики видят предупреждения, относящиеся только к новому или изменённому коду. С этого момента команда начинает получать пользу от статического анализа. Постепенно настраиваете анализатор и занимаетесь техническим долгом.

Отлично!

Кстати, система хранения неинтересных предупреждений достаточно умная. Хранятся хеши для строки с потенциальной ошибкой, а также для предыдущей и следующей. Благодаря этому, если в начало одного из файлов добавить строчку, то ничего «не разъедется» и анализатор по-прежнему будет молчать на код, считающийся техническим долгом.

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

Примечание

Ненайденные ошибки «оседают» в коде надолго, и затем многие из них могут быть выявлены при запуске статического анализа кода. При разработке любого проекта постоянно появляются и исправляются новые ошибки. Конечно, так оно и есть, если использовать анализатор неправильно и запускать его только время от времени, например, незадолго до выпуска релиза. Из-за этого иногда возникает ложное ощущение, что статические анализаторы находят только какие-то малоинтересные ошибки в редко используемых участках кода. Да, мы сами при написании статей выполняем разовые проверки открытых проектов. Подробнее эта тема разбирается здесь. Мы хотим продемонстрировать возможности анализатора кода по выявлению дефектов. Но у нас другая цель. Эта задача имеет мало общего с повышением качества кода проекта в целом и сокращением издержек, связанных с правкой ошибок.

Дополнительные ссылки:

  1. PVS-Studio ROI.
  2. Статический анализ улучшит кодовую базу сложных C++ проектов.
  3. Heisenbug 2019. Доклад Ивана Пономарёва "Непрерывный статический анализ кода".
  4. Иван Пономарев. Внедряйте статический анализ в процесс, а не ищите с его помощью баги.

Handling Objections: Static Analysis Will Take up Part of Working Time. Если хотите поделиться этой статьей с англоязычной аудиторией, то прошу использовать ссылку на перевод: Andrey Karpov.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть