Некоторые наши пользователи запускают статический анализ только время от времени. При этом находят новые ошибки в своем коде, радуются этому факту и с удовольствием продлевают лицензии на PVS-Studio. Казалось бы, надо и мне радоваться этому факту, но я печалюсь. Печалюсь я потому, что такое использование нашего инструмента дает лишь 10-20 процентов эффективности. В то время как вполне можно было бы получить как минимум 80-90 процентов пользы от статического анализа. В этой заметке я расскажу о наиболее часто встречающейся ошибке у тех, кто использует инструменты статического анализа кода.
Давайте сначала рассмотрим самый простой сценарий, который наиболее часто встречается у тех, кто пробует статический анализ кода. В команде разработчиков кто-то увидел статью, выступление на конференции или даже рекламу какого-то инструмента статического анализа и захотел попробовать его на своем проекте. Я сейчас говорю не обязательно про PVS-Studio, а о любом инструменте статического анализа. Человек с той или иной степенью легкости развернул у себя эту систему и запустил проверку кода. Дальше возможны следующие варианты:
Собственно практическое применение инструмента в команде начинается именно в третьем случае, когда нашлось что-то интересное.
Но тут, при внедрении статического анализа в процесс разработки, можно совершить очень большую ошибку. А именно – принять за правило запускать статический анализ, например, перед релизом. Или запускать статический анализ раз в месяц. Давайте рассмотрим, почему такой подход плох:
Во-первых, так как не используется механизм подавления ложных сообщений анализатора, то одни и те же старые ложные срабатывания выдаются вновь и вновь. Необходимо тратить время на их изучение. Чем больше сообщений выдает статический анализатор, тем более рассеяно внимание программиста.
Во-вторых, диагностические сообщения выдаются даже на тот код, который не трогался за это время. Это также увеличивает количество сообщений, которые необходимо будет проработать человеку.
В-третьих, и самое главное. При таком подходе статический анализ не выявит тех ошибок, которые медленно и печально находились другими способами между двумя запусками анализатора. Это настолько важный момент, что хочется остановиться на нем поподробнее. Это нужно сделать еще и потому, что про это забывают когда предлагают оценить пользу от статического анализа. Но об этом – в следующем разделе.
Некоторые люди предлагают использовать такой способ для оценки эффективности статического анализа кода. Вот команда работает над одним и тем же проектом несколько лет. И у нее, разумеется, есть все релизы этого проекта (1.0, 1.1., 1.2 и т.п.). Предлагается взять самую последнюю версию статического анализатора кода и прогнать ее на исходниках проекта прошлогодней давности. К примеру, на версии 1.3. Затем ту же версию статического анализатора кода прогнать на кодовой базе последнего релиза, к примеру, 1.7. Мы будем иметь два отчета от анализатора. Сначала мы проработаем первый отчет, выяснится, что в нем содержатся 50 реальных ошибок. Затем мы проработаем второй отчет и увидим, что в нем содержится 20 из тех 50 ошибок (и сколько-то новых, разумеется). Это значит, что 50-20 = 30 ошибок было исправлено альтернативными методами без статического анализатора кода. Например, эти ошибки были найдены или при ручном тестировании, или уже в релизе пользователями и т.п. В таком случае делается вывод, что статический анализатор помог бы быстро обнаружить и исправить 30 ошибок. И если это число велико, а время разработчиков дорого, то можно подсчитать экономическую целесообразность покупки и использования статического анализатора кода.
Данный подход к оценке экономической целесообразности категорически неверен! Его нельзя использовать для оценки статического анализатора! Дело в том, что при таком подходе допускается сразу несколько ошибок.
Во-первых, не учитываются ошибки, которые были внесены в версии кодовой базы 1.4 и устранены в версии 1.6. Вы можете сказать: "Значит надо сравнивать два соседних релиза, например 1.4 и 1.5!". Но и это неправильно, так как не учитываются ошибки, появившиеся после релиза 1.4 и исправленные до релиза 1.5.
Во-вторых, релизные версии кодовой базы сами по себе уже достаточно отлажены и в них содержится минимум ошибок. В отличие от текущей версии, над которой работают разработчики. Ведь вряд ли релиз был такой уж глючный и падающий. Скорее всего, ошибки исправляются между релизами, но обнаруживаются другими способами. Которые естественно более дорогие.
Здесь уместно напомнить табличку стоимости исправления дефектов в зависимости от времени их внесения и обнаружения. И важно понимать, что запуск статического анализа только "перед релизом" автоматически увеличивает стоимость исправления дефектов.
Таким образом оценить эффект от статического анализа запустив инструмент на прошлогоднем релизе кодовой базы и на текущем нельзя.
У нас за время работы в области статического анализа кода выработалось несколько рекомендаций, которые можно использовать для того, чтобы получить максимальную отдачу от таких инструментов. Хотя я буду указывать, как эти рекомендации мы поддерживаем в PVS-Studio, они годятся для любого инструмента статического анализа кода.
Любой статический анализатор кода дает ложные срабатывания. Такова природа этого инструмента и ничего поделать с этим нельзя. Естественно все стараются уменьшить количество ложных срабатываний, но сократить его до нуля невозможно. Для того чтобы повторно не смотреть на одни и те же ложные срабатывания хороший анализатор имеет механизм для подавления ложных срабатываний. Сообщение можно просто пометить как "ложное срабатывания" и при следующей проверке оно не будет выдано. В PVS-Studio за это отвечает функция "Mark As False Alarm". Подробнее смотрите в разделе документации про подавление ложных предупреждений.
Несмотря на свою простоту, это рекомендация может экономить массу времени. Более того, так как необходимо просматривать меньше сообщений, это можно сделать более внимательно.
Эффективный способ работы с инкрементальным анализом – это его интеграция в среду разработки (IDE) для того, чтобы инструмент автоматически запускался во время компиляции только что изменившихся файлов. В идеале желательно чтобы инкрементальный статический анализ запускался на машинах всех разработчиков, работающих над кодовой базой. В этом случае многие ошибки будут обнаружены и исправлены еще до того, как код попадет в систему контроля версий. Это очень сильно снижает "стоимость исправления ошибки". PVS-Studio поддерживает режим инкрементального анализа.
Если на все машины разработчиков поставить инструмент статического анализа не получается, то можно проверять код раз в несколько дней. Для того, чтобы не получать кучу сообщений про старые файл в инструментах статического анализа есть режим "проверять файлы, модифицированные за последние N дней". Например, за 3 дня. Хотя технически никто не мешает поставить в этот параметр любое число (хоть 7, хоть 10 дней), так делать не рекомендуется. Ведь если проверять только раз в 10 дней, то повторяется ошибка "периодического использования инструмента". Ведь если ошибка добавлена сегодня, завтра ее обнаружат тестировщики, послезавтра ее опишут в баг-трекере и через 5 дней исправят, то запуск статического анализа раз в 10 дней здесь не поможет.
А вот возможность проверять код раз в два-три дня может оказаться полезной. И PVS-Studio поддерживает эту возможность с помощью команды настроек "Check only Files Modified In".
Независимо от того используется ли инкрементальный анализ на машинах всех разработчиков или не используется, очень полезно каждую ночь делать полный прогон анализатора по всей кодовой базе. Соответственно очень важная возможность инструмента – это возможность вызова анализатора из командной строки, которую, конечно же, поддерживает PVS-Studio.
Перечислим еще раз рекомендации по повышению эффективности статического анализа кода:
Если у вас в команде будут использоваться все 4 рекомендации, то отдача от вложений в инструменты статического анализа будет максимальной. Конечно, по разным причинам, это не всегда возможно. Но стремиться к этому стоит.