Эта заметка будет интересна прежде всего менеджерам проектов и техническим руководителям, в командах которых используется анализатор кода PVS-Studio. В инструменте появилась возможность отслеживать эффективность использования статического анализатора в командах. Теперь вы можете в цифрах доказать босу, что анализатор купленный за несколько тысяч долларов приносит настоящую, видимую пользу. Но эта статья не про ROI, не пугайтесь.
Итак, какая проблема с инструментами статического анализа помимо того, что они стоят дорого? Не всегда команда, которая приобрела инструмент может похвастаться тем, что ошибки с его помощью правятся. А мы как никто другой заинтересованы в эффективном использовании нашего инструмента. Нас не устроит, если клиент просто купит лицензию и положит ее на полку. Ведь у нас более половины клиентов продлевают лицензии на следующий год. Поэтому наша задача показать эффективность использования нашего инструмента для тех, кто принимает решение о продлении лицензии.
Поэтому в PVS-Studio 5.27 появилась возможность строить графики количества ошибок, обнаруженных анализатором при проверке проекта. Идея этой возможности очень простая:
- Если вы хотите поправить все ошибки, которые выдает PVS-Studio, то со временем у вас график должен прийти к нулю.
- Если вы готовы мириться со старыми ошибками, но правите все новые, то у вас график не должен расти сильно вверх.
- В противном случае разработчики просто не используют PVS-Studio. К сожалению, и для нас (мы не получим продление лицензии), и для вас (вы зря потратили деньги на лицензию).
При каждой проверке всего кода (команда Check Solution) анализатор сохраняет в папке %AppData%\Roaming\PVS-Studio\Statistics небольшой XML файл в котором записано количество сообщений. В меню PVS-Studio есть команда Analysis Statistics, которая открывает диалог настройки показа статистики. Выберем временной интервал, выбираем интересные нам анализаторы и важность сообщений. Затем по кнопке «Show in Excel» открывается установленный на машине Microsoft Excel в котором строится нужный график.
Нет смысла долго рассказывать про этот диалог, все описано в документации. Поэтому давайте лучше рассмотрим возможные ситуации на примерах.
Как выглядит график, когда после внедрения все ошибки (и старые, и новые) правятся?
Рассмотрим первый пример. Компания купила PVS-Studio, начинает его внедрять. Пусть нас интересуют ошибки класса General Analysis (GA) причем для начала только наиболее важные и средние по важности. При первом запуске PVS-Studio выдает примерно 1800 сообщений. Сначала разработчики разбираются с наиболее очевидными ложными срабатываниями. Например, отключают их через подавление в макросах. Правят более простые ошибки, которые даются легко. Со временем скорость работы с сообщениями немного замедляется. Именно поэтому график имеем вид не прямой линии, а дугообразный.Ошибок становится все меньше и меньше, наконец когда-то их становится 0. Вот график, описывающий такой режим работы команды над ошибками PVS-Studio:
Рисунок 1 – Сначала правятся легкие ошибки, потом посложнее и самые сложные остаются в конце.
Все, все срабатывания анализатора проработаны, выдается 0 ошибок. Можно ли расслабиться? Нет. Ведь если расслабиться и дальше отключить анализатор (не править новые ошибки, то со временем количество ошибок начнет расти. Пример такого графика приведен на рисунке 2.
Рисунок 2 – После того как сначала все ошибки были исправлены, разработчики расслабились и перестали реагировать на сообщения анализатора.
Видите на этом графике показан рост количества сообщений? Это из-за того, что, доведя количество срабатываний до нуля, разработчики перестали править ошибки в новом коде. К счастью менеджер проекта вовремя спохватился и заметил, что ошибки не правят. Поэтому после разговоров с командой в проекте вновь стало 0 ошибок. И уже столько и поддерживалось в ежедневном режиме.
Пример неправильного вывода о результатах работы команды на основе графика
Ладно, а что можно сказать по графику на рисунке 3?
Рисунок 3 – Пример графика с двойным толкованием.
На первый взгляд можно сказать, что команда разленилась, ничего не правит и у нее растет количество ошибок. Причем довольно сильно – с 2700 до 3700 за период. Но этот вывод может сделать человек, совсем не знакомый с проектом. Если же знать, чем люди занимаются, то становится понятно. В проект добавлялся новый код в большом объеме (подключались новые проектные файлы к общему решению .sln). И ничего страшного в таком графике нет. Ведь дальше количество проектов стабилизируется, ошибки расти сильно не будут, если команда начнем их править вовремя.
Этот график приведен как пример того, что нельзя «влоб» интерпретировать данные статистики, нужно еще понимать, что делает команда в тот или иной момент времени.
Откуда берутся ступеньки?
Нередко правильный вид графика при равномерной работе напоминает ступеньки как на рисунке 4.
Рисунок 4 – Ступенчатый график.
Такой ступенчатый график – самый правильный, ведь он означает равномерную работу команды по исправлению ошибок. Догадались откуда берутся ступеньки, когда количество ошибок не уменьшается? Конечно же это выходные.
Как выглядит график «только новых» ошибок?
Ладно, до этого были примеры, когда команда работала над исправлением всех ошибок, которые выдает анализатор кода. Но ведь суть функции "массового подавления ошибок" в том, чтобы сказать: «Ладно, мы знаем, что у нас есть много сообщений PVS-Studio на старый код. Но сейчас мы хотим закрыть на него глаза и править ошибки только в новом коде». Как будет выглядеть график ошибок в этом случае? Рисунок 5 отвечает на этот вопрос.
Рисунок 5 – График количества ошибок для только нового кода.
Хотя на первый взгляд график выглядит хаотично, именно так и должен выглядеть нормальный рабочий процесс с использованием анализатора кода. Что имеется ввиду? Обратите внимание на масштаб по оси Y. Максимальное значение здесь 8 – это максимум, сколько ошибок (срабатываний анализатора) было добавлено за один день. Скажете, что это много? Но если речь о команде в 50 разработчиков и 9 млн строка кода, то согласитесь, это очень даже неплохой результат. Но гораздо важнее то, что эти правятся на следующий день.
Какой правильный сценарий использования PVS-Studio, чтобы «график был идеальный»?
Итак, мы поняли, как выглядят «неправильные» графики и как выглядят «правильные». Но как должен быть построен процесс разработки для того, чтобы графики ошибок PVS-Studio были «правильными»? Что должен организовать менеджер проекта или технический руководитель?Вот шаги, которые приведут к наиболее эффективному результату:
- Настройте ежедневную проверку кода с помощью PVS-Studio на сборочном сервере. Это поможет вам контролировать процесс правки ошибок и накапливать историю, которую легко затем визуализировать.
- Всем разработчикам установите PVS-Studio и включите режим инкрементального анализа. В этом режиме PVS-Studio следит за тем, какие файлы правит разработчик на своей машине. И после их успешной компиляции автоматически проверяет. В случае обнаружения ошибок они будут конечно показаны. Преимущество такого режима в том, что разработчику не надо явно запускать анализатор. И увидев сообщение от него, он может сразу исправить код. В этом случае ошибочный код даже не попадет в систему контроля версий.
- Если все-таки ошибочный код попадет в систему контроля версий, то при ночной проверке он будет обнаружен. Очень важно, чтобы утром разработчики увидели отчет по результатам ночного запуска. Тогда они смогут исправить ошибки. PVS-Studio автоматически формирует файл-отчет с найденными ошибками в формате .html, который можно разослать заинтересованным лицам.
