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

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

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

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

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

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

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

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

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

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

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

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

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

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

Примечание

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

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