Для получения триального ключа
заполните форму ниже
Team License (базовая версия)
Enterprise License (расширенная версия)
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

** На сайте установлена reCAPTCHA и применяются
Политика конфиденциальности и Условия использования Google.
Запросите информацию о ценах
Новая лицензия
Продление лицензии
--Выберите валюту--
USD
EUR
GBP
RUB
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

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

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

** На сайте установлена reCAPTCHA и применяются
Политика конфиденциальности и Условия использования Google.
Мне интересно попробовать плагин на:
* Нажимая на кнопку, вы даете согласие на обработку
своих персональных данных. См. Политику конфиденциальности

** На сайте установлена reCAPTCHA и применяются
Политика конфиденциальности и Условия использования Google.
Ваше сообщение отправлено.

Мы ответим вам на


Если вы так и не получили ответ, пожалуйста, проверьте папку
Spam/Junk и нажмите на письме кнопку "Не спам".
Так Вы не пропустите ответы от нашей команды.

>
>
Регулярное использование статического а…

Регулярное использование статического анализа кода в командной разработке

Технологии статического анализа кода применяются в компаниях со зрелыми процессами разработки программного обеспечения. Однако уровень применения и внедрения в процесс разработки инструментов анализа кода может быть различным. Начиная от ручного запуска анализатора "время от времени" или при поиске трудноуловимых ошибок, и кончая ежедневным автоматическим запуском или запуском при добавлении нового исходного кода в систему контроля версий.

В статье рассмотрены различные уровни использования технологий статического анализа кода в командной разработке, показано как "перевести" процесс с одного уровня на другой. В качестве примера в статье используется разрабатываемый авторами анализатор кода 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, которую можно купить и использовать без каких-либо взаимодействий с поставщиком. Всегда рассчитывайте на то, что необходимо плотно общаться с разработчиками анализатора, а процедура внедрения инструмента требует сил и времени.
  • Статический анализатор повышает общую культуру разработки программного обеспечения в команде, но только если команда сама готова к этому повышению. То есть это процесс взаимный.
  • Повышение культуры разработки через использование статических анализаторов кода процесс дорогостоящий. К этому надо быть готовым и понимать, что это потребует существенных вложений.

Библиографический список

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

Дата: 21 Ноя 2018

Автор: Андрей Карпов

Краткое описание технологий, используемых в инструменте PVS-Studio, которые позволяют эффективно обнаруживать большое количество паттернов ошибок и потенциальных уязвимостей. Статья описывает реализа…
Зло живёт в функциях сравнения

Дата: 19 Май 2017

Автор: Андрей Карпов

Возможно, читатели помнят мою статью под названием "Эффект последней строки". В ней идёт речь о замеченной мной закономерности: ошибка чаще всего допускается в последней строке однотипных блоков текс…
PVS-Studio ROI

Дата: 30 Янв 2019

Автор: Андрей Карпов

Время от времени нам задают вопрос, какую пользу в денежном эквиваленте получит компания от использования анализатора PVS-Studio. Мы решили оформить ответ в виде статьи и привести таблицы, которые по…
Статический анализ как часть процесса разработки Unreal Engine

Дата: 27 Июн 2017

Автор: Андрей Карпов

Проект Unreal Engine развивается - добавляется новый код и изменятся уже написанный. Неизбежное следствие развития проекта - появление в коде новых ошибок, которые желательно выявлять как можно раньш…
Характеристики анализатора PVS-Studio на примере EFL Core Libraries, 10-15% ложных срабатываний

Дата: 31 Июл 2017

Автор: Андрей Карпов

После большой статьи про проверку операционной системы Tizen мне было задано много вопросов о проценте ложных срабатываний и о плотности ошибок (сколько ошибок PVS-Studio выявляет на 1000 строк кода)…
Как PVS-Studio оказался внимательнее, чем три с половиной программиста

Дата: 22 Окт 2018

Автор: Андрей Карпов

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

Дата: 31 Май 2014

Автор: Андрей Карпов

Я изучил множество ошибок, возникающих в результате копирования кода. И утверждаю, что чаще всего ошибки допускают в последнем фрагменте однотипного кода. Ранее я не встречал в книгах описания этого …
Бесплатный PVS-Studio для тех, кто развивает открытые проекты

Дата: 22 Дек 2018

Автор: Андрей Карпов

В канун празднования нового 2019 года команда PVS-Studio решила сделать приятный подарок всем контрибьюторам open-source проектов, хостящихся на GitHub, GitLab или Bitbucket. Им предоставляется возмо…
Главный вопрос программирования, рефакторинга и всего такого

Дата: 14 Апр 2016

Автор: Андрей Карпов

Вы угадали, ответ - "42". Здесь приводится 42 рекомендации по программированию, которые помогут избежать множества ошибок, сэкономить время и нервы. Автором рекомендаций выступает Андрей Карпов - тех…
Любите статический анализ кода!

Дата: 16 Окт 2017

Автор: Андрей Карпов

Я в шоке от возможностей статического анализа кода, хотя сам участвую в разработке инструмента PVS-Studio. На днях я был искренне удивлён тому, что анализатор оказался умнее и внимательнее меня.

Комментарии (0)

Следующие комментарии

На сайте установлена reCAPTCHA и применяются
Политика конфиденциальности и Условия использования Google.
Этот сайт использует куки и другие технологии, чтобы предоставить вам более персонализированный опыт. Продолжая просмотр страниц нашего веб-сайта, вы принимаете условия использования этих файлов. Если вы не хотите, чтобы ваши данные обрабатывались, пожалуйста, покиньте данный сайт. Подробнее →
Принять