В преддверии выхода примерно в сентябре статического анализатора от Intel под названием Advisor, который войдет в Intel Parallel Studio 2011, нелишне будет в целом рассказать о технологии статического анализа кода и об ее применении. Дело в том, что по опыту в России статический анализ применяется не часто, видимо из-за того, что у нас не так много сложных программных проектов. Поэтому краткий текст на тему что это и кому может быть полезно, надеюсь, окажется кстати. Ну и кому же как не авторам анализатора PVS-Studio этот текст делать? :-)
Аннотация
Технологии статического анализа кода применяются в компаниях со зрелыми процессами разработки программного обеспечения. Однако уровень применения и внедрения в процесс разработки инструментов анализа кода может быть различным. Начиная от ручного запуска анализатора "время от времени" или при поиске трудноуловимых ошибок, и кончая ежедневным автоматическим запуском или запуском при добавлении нового исходного кода в систему контроля версий.
В статье рассмотрены различные уровни использования технологий статического анализа кода в командной разработке, показано как "перевести" процесс с одного уровня на другой. В качестве примера в статье используется разрабатываемый авторами анализатор кода PVS-Studio.
Введение
Статический анализатор кода - это инструмент для поиска программных ошибок по исходному коду. Применение такого инструмента помогает избежать выявления программных ошибок еще на этапе разработки, а не на этапах тестирования или использования.
Однако далеко не всегда компаниям удается получить выгоду от подобных инструментов. Причины этого самые разные. Какие-то проекты просто экономически не подходят для внедрения анализатора кода, какие-то проекты не достаточно большие, чтобы эффект был заметен. Поэтому перед внедрением в процесс разработки статического анализа кода необходимо понимать, когда это может принести пользу, а когда - нет.
В статье на основе опыта авторов (занимающихся разработкой, продвижением и продажей собственного статического анализатора кода) сформулированы основные соображения, которыми стоит руководствоваться при внедрении подобных инструментов в процесс разработки.
Что такое статический анализ кода
Статический анализ кода - это технология поиска ошибок в программах путем разбора исходного кода и поиска в нем паттернов (шаблонов) известных ошибок. Эта технология реализуется специальными инструментами, называемыми статическими анализаторами кода.
Слово "статический" означает, что код разбирается без запуска программы на выполнение. Инструменты, которые анализируют программу во время ее работы, называются динамическими анализаторами кода.
Наиболее известные статические анализаторы выпускают компании Coverity, Klocwork, Gimpel Software. Популярные динамические анализаторы делают компании Intel (Intel Parallel Inspector) и Micro Focus (DevPartner Bounds Checker). Необходимо также упомянуть специализированный статический анализатор кода PVS-Studio, разработкой и продвижением которого занимаются авторы статьи.
Результат работы статического анализатора - это список обнаруженных в коде потенциальных проблем с указанием имени файла и конкретной строки. Другими словами, это список ошибок, очень похожий на тот, что выдает компилятор. Термин "потенциальные проблемы" используется здесь не случайно. К сожалению, статический анализатор не может абсолютно точно сказать, является ли эта потенциальная ошибка в коде реальной проблемой. Это может знать только программист. Поэтому, увы (и это неизбежно), анализаторы кода дают ложные срабатывания.
Инструменты для статического анализа кода делятся по типу поддерживаемых языков программирования (Java, C#, C, C++), по диагностируемым проблемам (анализаторы общего назначения или специализированные, например, для разработки 64-битных или параллельных программ).
Для каких проектов актуален статический анализ кода
Статический анализ кода целесообразно применять не во всех проектах, а только в средних и крупных. Дискуссия на тему что считать малым/средним/большим проектом явно выходит за рамки данной статьи, однако по своему опыту мы рекомендуем задуматься о применении статического анализа в проектах, размер которых более 30 человеко-месяцев. Если программный проект меньше указанного размера, то вместо использования статического анализа достаточно иметь в проекте нескольких квалифицированных разработчиков. Команда из двух-четырех квалифицированных сотрудников вполне потянет такой проект и сможет сделать его качественно с программной точки зрения. Но вот если над проектом работают либо больше людей, либо проект длиться более полугода, то надеяться на то, что "надо просто писать без ошибок" достаточно наивно.
Варианты (сценарии) использования статических анализаторов кода
Рассмотрим ситуации, при которых команда разработчиков может прийти к необходимости использовать статический анализ кода. Здесь намеренно рассматривается случай, когда статический анализ только появляется в процессе разработки - ведь если статический анализ давно уже внедрен и используется, то и обсуждать вопросы внедрения не имеет смысла.
Итак, предположим, команда из 5 человек занимается тем, что выполняет перенос кода программного проекта для работы на 64-битных компьютерах. Предположим также, что код проекта написан на C/C++. Заранее скажем, что такие предпосылки сделаны для того, чтобы в примере можно было использовать наш анализатор кода PVS-Studio. Разработчики исправили основные ошибки компиляции, собрали приложение, дистрибутив. Начали тестировать и выяснили, что в программе есть крайне загадочные ошибки, которые проявляются только в 64-битной версии программы. Разработчики идут в Google, вводят "64-bit platform с++ issues" и среди 8.5 млн результатов на первой странице находят ссылку на нашу статью "20 issues of porting C++ code on the 64-bit platform" (в русском варианте "20 ловушек переноса Си++ - кода на 64-битную платформу"), из которой узнают, что оказывается в C/C++ приложениях при разработке 64-битных версий программ проявляются разные незаметные ранее проблемы. Там же они узнают, что есть инструмент PVS-Studio, который позволит эти проблемы найти и исправить. Далее разработчики скачивают инструмент, смотрят на ознакомительную версию, если он их устраивает, то покупают лицензию, находят с помощью инструмента сколько-то ошибок в своем коде, исправляют их, и программа оказывается без ошибок. После чего разработчики считают задачу создания 64-битной версии программы законченной и далее отказываются от использования анализатора, так как считают, что он им не нужен больше.
Другой сценарий, близкий к этому. При разработке Java-приложения команда из 5 разработчиков столкнулась с ошибкой в одном из сторонних модулей. К сожалению, найти ошибку в коде "глазами" не получилось, разработчики скачали ознакомительную версию какого-либо анализатора кода для Java, с его помощью нашли ошибку в этом стороннем модуле, исправили ее, но покупать лицензию на инструмент не стали - ограничения бюджета проекта. Ошибка исправлена, приложение выпущено, лицензия на инструмент не нарушена. Вроде бы все нормально, но и этот вариант использования статического анализатора нельзя назвать правильным.
Третий вариант использования. Разработчики перешли на использование Visual Studio Team Foundation Server, в котором есть возможность запускать анализ кода для файлов, добавляемых в систему контроля версий. Несколько недель спустя, разработчики отключили проверку кода, поскольку добавление нового кода превратилось в игру "убеди анализатор разрешить добавить файл".
Все эти три рассмотренных варианта использования не являются удачными случаями применения статического анализа. И это несмотря на то, что в первых двух случаях анализатор помог найти реальные ошибки в коде, а в третьем код программистов видимо был откровенно плох. В чем же причины этих неудач?
Что мешает полноценному использованию статического анализатора кода
Покажем причины того, что перечисленные выше три варианта использования статического анализа не являются удачными случаями применения.
Если команда применяет специализированный анализатор кода (как в описанном случае для поиска проблем 64-битного кода), то очень велик соблазн отказаться от инструмента после того, как проблемы вроде бы найдены и исправлены. И действительно, если выпущена 64-битная версия программного продукта, может показаться, что дальше использовать специальный инструмент смысла нет. Однако это не так. Если отказаться от использования такого анализатора, то со временем (через несколько месяцев) уже в новом коде будут возникать те ошибки, которые могли бы быть обнаружены с использованием анализатора кода. То есть, хотя 64-битная версия приложения существует и (когда-то) была отлажена, новый код может содержать ошибки, характерные для 64-битных приложений. Вывод по первому сценарию использования - отказ от специализированного анализатора кода после того, как основная работа с ним закончена, приводит к скорому появлению новых программных ошибок подобного типа.
Во втором описанном случае команда решила применить специализированный инструмент только тогда, когда уже стало очевидным наличие трудно обнаруживаемых ошибок в проекте. И после исправления этих ошибок команда отказалась от инструмента. Проблема в этом подходе в том, что трудно обнаруживаемые ошибки снова рано или поздно появятся в проекте. Но, возможно, сначала их теперь уже увидят пользователи, а не разработчики или тестировщики. Вывод по второму сценарию использования совпадает с первым выводом - отказ от инструмента обязательно приведет вновь к появлению трудно обнаруживаемых ошибок.
В третьем сценарии использования, когда из-за трудностей добавления нового кода в систему контроля версий от статического анализа при добавлении кода решено было отказаться, вообще проблема не в статическом анализаторе, а в недостаточном уровне команды. Во-первых, команда не смогла настроить инструмент так, чтобы его сообщения были полезными. А, во-вторых, видимо код действительно был не очень хорошим, раз анализатор выдавал много диагностических сообщений.
Итак, сформулируем основные проблемы, которые мешают использовать постоянно в работе инструменты статического анализа кода:
- Высокая цена инструментов анализа кода не позволяет применять эти инструменты в малых (прежде всего по бюджету) проектах. Надо просто понимать, что есть проекты, в которых статический анализ не подходит не из-за технологических, а из-за экономических причин.
- Инструмент для анализа кода дает много ложных срабатываний. Увы, любой анализатор кода дает ложные срабатывания и зачастую дает их довольно много. Причина здесь кроется в философии подобных инструментов. Лучше выдать десять-сто ложных сообщений, чем пропустить одно настоящее. Надеяться на то, что какие-то анализаторы выдают мало ложных срабатываний не стоит. Лучше выбрать инструмент, который каким-то образом поддерживает возможность работы с ложными срабатываниями. Например, наш анализатор PVS-Studio содержит функцию "Mark as False Alarm". С ее помощью можно разметить ложные срабатывания анализатора прямо в коде. То есть указать, что анализатор не должен выдавать такой-то тип сообщений в такой-то строке.
- Плохая интеграция в среду разработки. Если инструмент для анализа кода не имеет гладкой "бесшовной" интеграции в среду разработки, то вряд ли им будут пользоваться регулярно.
- Отсутствие возможности автоматизированного запуска с помощью командной строки. Это не позволяет выполнять анализ кода всего проекта регулярно, например, во время ежедневных сборок.
- Отсутствие возможности интеграции с системой контроля версий. Хотя в рассмотренном ранее примере проверка нового кода при добавлении его в систему контроля версий послужила отказом от использования подобных инструментов, все-таки сама возможность такой интеграции является полезной.
- Слишком сложные, либо наоборот слишком простые настройки анализатора кода.
Решением здесь является взаимодействие компании, которая хочет использовать технологии статического анализа кода с компанией, которая эти технологии предоставляет. То есть отношения из разряда "купить инструмент и использовать его" переходят в разряд "купить решение, внедрить его и только потом использовать". Нравится это или нет, но в большинстве случаев просто купить "программку-анализатор" и использовать ее с выгодой не удастся. Нужно "подтянуть" процесс разработки в компании и вместе с поставщиком решений для статического анализа внедрить предлагаемый им инструмент в постоянный регулярный процесс командной разработки.
По такой схеме работают лидеры рынка статического анализа вроде Coverity или Klocwork. Это кстати имеет, может быть, не совсем понятное внешнее проявление. У этих компаний не так-то просто получать хоть какую-то ознакомительную версию с сайта. А уж добиться ответа на вопрос "сколько стоит" и вовсе не возможно до тех пор, пока sales-менеджеры не узнают о клиенте максимум информации.
Заключение
Если ваша компания планирует применять статический анализ кода, то необходимо учитывать следующее:
- Внедрение статического анализа кода оказывает влияние на весь процесс разработки.
- Статический анализатор - это не мелкая утилита и не очередная копия Windows, которую можно купить и использовать без каких-либо взаимодействий с поставщиком. Всегда рассчитывайте на то, что необходимо плотно общаться с разработчиками анализатора, а процедура внедрения инструмента требует сил и времени.
- Статический анализатор повышает общую культуру разработки программного обеспечения в команде, но только если команда сама готова к этому повышению. То есть это процесс взаимный.
- Повышение культуры разработки через использование статических анализаторов кода процесс дорогостоящий. К этому надо быть готовым и понимать, что это потребует существенных вложений.