Как в PVS-Studio мы решали одну инженерную задачу в течение нескольких лет

03 Авг 2011

Автор: Евгений Рыжков

Сначала я хотел назвать эту заметку "Как PVS-Studio позволяет ДЕШЕВО внедрить статический анализ кода в процесс разработки", но не решился из-за двусмысленного толкования слова "дешево". Поэтому я расскажу об одной инженерной проблеме, которую мы постоянно должны были решать для того, чтобы люди пользовались нашим продуктом. Забегая вперед, скажу, что, как мне кажется, мы ее решили.

Итак, разработав в начале 2007 года первую версию статического анализатора кода (который тогда назывался Viva64 и выявлял 64-битные ошибки), мы столкнулись с проблемой внедрения инструмента у клиентов. Наш клиент – это компания, в которой как минимум несколько десятков разработчиков, и хотя бы несколько сотен тысяч строк кода. Любой статический анализатор на такой код выдаст кучу предупреждений. Например, мы своим инструментом получали до нескольких тысяч сообщений на один проект.

Да, конечно же, здесь проблема с ложными срабатываниями анализатора. Однако у любого анализатора есть ложные срабатывания и от них никуда не деться. Встал вопрос – что делать с большим количеством сообщений, которые получает пользователь? То есть проблема выглядит так. Потенциальный пользователь скачивает программу (trial), запускает ее и получает десять тысяч сообщений. Естественно, его это печалит, затем uninstall и мы потеряли клиента.

Первое что мы сделали – это сразу же убрали дублирующиеся сообщения. Анализатор проверяет проекты на C/C++ и бывает, что ошибка в .h-файле может выдаваться при проверке нескольких .cpp-файлов, которые его используют. У нас это не дублируется. Затем мы добавили возможности фильтрации результатов анализа (и постоянно их совершенствовали): фильтрация по коду ошибки, по тексту сообщения, возможность не проверять файлы по маске и т.п. Все это позволяло существенно снизить количество сообщений, но только после настройки. Пользователь в первый раз все так же получал гору сообщений. Таким образом, фильтрация сообщений – это важный инструмент, но он не решал исходную проблему – трудность внедрения инструмента в процесс разработки.

Затем в анализаторе появился новый механизм "Mark as False Alarm". Это вставка в код комментариев специального вида (//-V112) для подавления сообщений анализатора. Разметив код таким образом в дальнейшем можно получать сообщения о проблемах только в тех фрагментах кода, где такой разметки пока нет. В идеале это только новый код. Хотя проблема внедрения анализатора в процесс разработки команды стала чуть более простой, все равно, нужно чтобы несколько человек из команды сначала разметили код, избавив от явно мусорных сообщений.

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

Поэтому мы пошли дальше и сделали новую супер возможность "Incremental Analysis after Build". Теперь анализатор запускается сразу после компиляции и проверяет только те файлы, которые были "задеты" правками пользователя. В отличие от проверки файлов за несколько дней (когда могли проверяться правки команды разработчиков), теперь пользователь видит ТОЛЬКО ошибки в том коде, который он непосредственно трогает.

Программист теперь не будет беспокоиться о большом объеме кода, который он не трогает. Возможно этому коду уже более 5 лет. Он практически не модифицируется и большинство дефектов в нем уже исправлено. Этот код не надо бросаться проверять в первую очередь и анализатор этого и не делает. Программист будет видеть предупреждения только в свежем коде. А уж если у него будет дополнительное время, он всегда сможет проверить проект целиком, заглянув в самые редко посещаемые места.

Да, все равно есть ложные срабатывания анализатора. Да, все равно не потеряли свою актуальность фильтры. Но важное другое. Стоимость ВНЕДРЕНИЯ (затраты сил людей на ввод в эксплуатацию) статического анализатора нам удалось сократить до нуля. То есть теперь человек скачивает статический анализатор, устанавливает его и СРАЗУ же начинает получать выгоду от него без каких-либо дополнительных действий.

Однако не хватало завершающего штриха. Всё бы хорошо, но вот только то, что анализатор нашёл ошибки, было очень плохо заметно. Смена цвета иконки окна PVS-Studio (как мы сделали сначала) не так заметна, а в Visual Studio 2005 это и вовсе не наработает. Решением стало всплывающее уведомление.

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

Таким образом, инженерная задача по внедрению статического анализа в процесс разработки была решена. Поэтому в PVS-Studio 4.34 режим Incremental Analysis after Build будет по умолчанию включен.

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