Эта заметка будет интересна прежде всего менеджерам проектов и техническим руководителям, в командах которых используется анализатор кода PVS-Studio. В инструменте появилась возможность отслеживать эффективность использования статического анализатора в командах. Теперь вы можете в цифрах доказать боссу, что анализатор купленный за несколько тысяч долларов приносит настоящую, видимую пользу. Но эта статья не про ROI, не пугайтесь.
Итак, какая проблема с инструментами статического анализа помимо того, что они стоят дорого? Не всегда команда, которая приобрела инструмент может похвастаться тем, что ошибки с его помощью правятся. А мы как никто другой заинтересованы в эффективном использовании нашего инструмента. Нас не устроит, если клиент просто купит лицензию и положит ее на полку. Ведь у нас более половины клиентов продлевают лицензии на следующий год. Поэтому наша задача показать эффективность использования нашего инструмента для тех, кто принимает решение о продлении лицензии.
Поэтому в PVS-Studio 5.27 появилась возможность строить графики количества ошибок, обнаруженных анализатором при проверке проекта. Идея этой возможности очень простая:
Прежде чем смотреть конкретные графики, буквально пара слов о технологии.
При каждой проверке всего кода (команда 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 были "правильными"? Что должен организовать менеджер проекта или технический руководитель?
Вот шаги, которые приведут к наиболее эффективному результату:
Если команда сможет войти в такой режим использования анализатора кода, то внедрение инструмента не будет напрасным. А вопрос о продлении лицензии на следующий год решится сам собой.