Использование средств статического анализа для автоматической проверки кода может облегчить работу разработчиков ПО. Такой способ поиска ошибок или недочетов в коде программного обеспечения может быть быстрее и дешевле, чем ручная проверка. Исследование показывает, что даже несмотря на эти преимущества, статические анализаторы недостаточно распространены в использовании. В данной статье мы рассмотрим причины, по которым статические анализаторы не используются разработчиками повсеместно, и возможности для улучшения статических анализаторов. Мы руководствовались мнением 20 опрошенных разработчиков и обнаружили, что ошибочные срабатывания и вид предупреждений могут поставить под вопрос использование анализаторов, даже несмотря на то, что многие считают их использование выгодным. В этой статье также мы сделаем выводы из проведенного опроса. Один из таких выводов — необходимость дать разработчикам удобный инструмент для исправления багов после их обнаружения анализатором.
Материал был переведён и опубликован в нашем блоге с согласия авторов. В конце статьи мы добавили небольшой раздел, касающийся анализатора PVS-Studio и того, какие из описанных в статье рекомендаций реализованы в анализаторе, какие нет и почему.
Возрастание доверия к программному обеспечению повышает важность его качества. Существует множество способов для обеспечения качества ПО, в том числе - ревью кода и тестирование. Недоработки в ПО или ошибки могут стоит компаниям кругленькую сумму денег, особенно в тех случаях, когда они приводят к сбоям [1], [2].
Инструменты статического анализа кода позволяют проверять код без его запуска, помогая обеспечить высокое качество программ на протяжении всего процесса разработки. Существует множество инструментов для статического анализа кода в процессе разработки ПО, в том числе непосредственно перед выкладкой исходного кода в систему контроля версий. Инструмент может позволить разработчику указать, какой тип ошибок должен диагностироваться, а также дает возможность установить свои правила для поиска ошибок. Некоторые автоматические статические анализаторы, например, интегрированные в IntelliJ IDEA [4], обеспечивают быстрое исправление багов. Оно применяется автоматически к коду разработчика. Чтобы разобраться в данном нововведении, давайте взглянем на работу такого инструмента на конкретном примере - FindBugs [5]. FindBugs используется в качестве плагина для интегрированных сред разработки (IDE) Eclipse [7] и NetBeans [8]. Также он может быть запущен из командной строки и отдельно, в качестве самостоятельного инструмента. При запуске в среде IDE у FindBugs есть собственный список, где перечислены и упорядочены все ошибки. Каждой ошибке присвоена соответствующая степень серьезности: высокая, средняя или низкая, каждая из которых имеет свой цвет: красный, желтый и зеленый. FindBugs предлагает исправить ошибку одним из предложенных способов.
Существует множество ситуаций, когда разработчик размышляет об использовании статического анализатора, чтобы найти ошибки в коде. Давайте побеседуем об этом с разработчиком - Сьюзи. Сьюзи - разработчик программного обеспечения в маленькой компании. Она хочет быть уверена, что соблюдает стандарты компании и пишет качественный код. Она нуждается в проверке кода в среде IDE перед отправкой его в общий репозиторий кода, не беспокоясь о каких-либо внешних сложностях, над которыми она не имеет контроля. Она устанавливает FindBugs, потому что ей нравятся результаты проверки и то, что ошибки могут быть найдены в процессе написания кода. Она довольна своим решением и чувствует свою продуктивность при его использовании.
Вышеописанный сценарий - это опыт одного из участников нашего интервью. Методы статического анализа используют определенные правила, чтобы найти ошибки уже на ранней стадии разработки, когда не так дорого их исправить. Например, есть методы статического анализа, которые могут предупредить разработчика об ошибке синхронизации, способной привести к ряду опасных взаимодействий. Методы статического анализа, внедренные в статические анализаторы, помогли разработчикам устранить многие ошибки, которые ранее упускались в крупных компаниях.
Несмотря на преимущества статического анализатора для поиска ошибок, данный инструмент используется редко [6]. Помните Сьюзи, которая установила статический анализатор, чтобы улучшить качество ее кода? По прошествии некоторого времени использования статического анализатора интерфейс оказался неудобным, не так легко было найти ошибки, а когда это все же получалось, то приходилось долго разбирать ответ. Ревью кода без статического анализатора заняло больше времени, но тем не менее она предпочла этот метод, несмотря на затраты, так как удалось избежать путаницы в работе с кодом. Были проведены исследования, чтобы улучшить работу статического анализатора. Тем не менее, никто не изучил, что делает и что может сделать статический анализатор для разработчика, какие функции использует разработчик, что нужно исправить и почему [10], [11]. Суть нашего исследования состоит в том, чтобы разобраться, почему разработчики программного обеспечения не используют статический анализатор и как стоит улучшить ныне существующие анализаторы, чтобы расширить их использование. Для нашего исследования мы намерены сосредоточиться на инструментах статического анализа, используемых для нахождения багов. К этим инструментам относятся FindBugs, Lint [12] , IntelliJ [4] (который включает в себя встроенный статический анализатор) и PMD [13]. Больше всего мы будем ссылаться на FindBugs, так как этот инструмент мы использовали во время наших интервью.
В следующей части данной статьи, мы сперва рассмотрим некоторые связанные работы (Раздел II), а также методы, используемые в нашем исследовании (Раздел III). В разделе IV представлены результаты нашего исследования. В V разделе мы обсудим то, что влияет на статические анализаторы, закончим обсуждением будущей работы (Раздел VI) и рассмотрим пункты (Раздел VII).
Было проведено множество исследований о точности и функциональности статических анализаторов [6], [10], [14], [15]. В отличие от уже существующих работ, наша работа направлена на восприятие разработчиками статических анализаторов, в том числе - на взаимодействие с интерфейсом анализатора.
Восприятие играет огромную роль при взаимодействии человека и компьютера и может зависеть от целого ряда вещей, таких как личные предпочтения пользователя.
Айевах и Пью провели исследование, в котором они утверждают, что статические анализаторы должны помочь инженерам находить баги как можно раньше в процессе разработки, когда их исправление обходится ещё дешево [17]. Они опросили 12 пользователей FindBugs по телефону и лично исследовали взаимодействие 12 студентов с FindBugs, чтобы увидеть, как они используют анализатор и справляются с багами с пометкой "not a bug". Их исследование похоже на наше исследование:также как и мы, они хотят узнать, как разработчики используют статические анализаторы. Наша работа строится посредством интервьюирования.
Хуу и другие изучали интерфейсы статических анализаторов и способы их улучшения [11]. Они разработали пользовательский набор инструментов под названием Path Projection, который помогает разработчикам перемещаться по отчетам об ошибках, производимых анализатором. Path Projection был разработан для улучшения и упрощения процесса сортировки сообщений об ошибках или маркировки ложных срабатываний первого или второго рода, используя контрольные списки для их систематической маркировки. Это исследование похоже на нашу работу тем, что оно направлено на улучшение работы пользователя с инструментами статического анализа. Наш эксперимент полагается на данное исследование, потому что оно не только исследует, как улучшить работу пользователя, но также пытается выяснить у самих разработчиков, почему эти усовершенствования должны быть сделаны.
Хекман и Вильямс провели исследование в попытке разработать тест под названием FAULTBENCH, который поможет разработчикам сравнить и оценить приоритеты оповещений статического анализатора и классификацию материала. Общая цель их исследования состоит в том, чтобы сделать работу с помощью статических анализаторов проще и полезнее для разработчиков. Мы тоже ищем пути для улучшения текущих инструментов статического анализа для них. Лайман и другие привлекли к участию 18 добровольцев для исследования факторов, которые разработчики могут учитывать при принятии решения считать ли ошибку серьезной, когда появляется о ней уведомление [19]. Данное исследование похоже на наше тем, что также используется схожая методология, и они тоже заинтересованы в получении дополнительной информации о том, как разработчики используют эти инструменты и как его можно облегчить. Наша работа строится на этих исследованиях, сосредоточив внимание на различных аспектах использования инструментов статического анализа, включая в себя то, как пользователи взаимодействуют с инструментами.
Для нашего исследования мы провели интервью с разработчиками ПО. Каждое интервью длилось примерно 40-60 минут и, с согласия участника, было записано. При проведении такого интервью мы стремились добиться гибкости, необходимой, чтобы получить как можно более подробную информацию [24]. Мы подготовили перечень вопросов для интервью, но на деле мы опустили некоторые, в зависимости от детальности ответов участника. Мы изменили перечень после того, как провели несколько пробных интервью; любые изменения были внесены на основе ответов, которые мы получили от наших 4 пробных участников [25].
После завершения мы вручную разобрали каждое интервью. Это мы подробнее рассмотрим в Разделе III-F.
Мы провели это исследование с группой из 20 участников. Может показаться, что этого количества участников мало. Тем не менее, мы следовали методике аналогичной Лайману и др. -- в его исследовании приняло участие 18 человек [19]. Участники были выбраны с помощью электронной рассылки, которая была отправлена разработчикам нашей компании. Шестнадцать из наших участников - это профессиональные разработчики крупной компании и 4 аспиранта Государственного Университета Северной Каролины с опытом работы в сфере разработки промышленного ПО. Опыт работы участников варьировался от 3 до 25 лет. Мы не спрашивали напрямую у участников об их опыте работы по созданию статических анализаторов, однако, в беседах выяснилось , что примерно 2 участника имели опыт в создании подобных инструментов. Мы взяли интервью у двух участников удаленно: одного опросили по телефону и еще одного - по видео-чату, в силу их удалённого местонахождения. Каждый участник заполнил небольшую анкету, используемую для сбора демографической информации.
Таблица 1. Описательная статистика по результатам опроса участников.Таблица 1 показывает статистику и справочную информацию, собранную из анкет и интервью. В первом столбце перечислены псевдонимы участников, указанные в целях конфиденциальности. Второй и третий столбцы показывают инструменты с открытым и закрытым исходным кодом, которые они использовали, чтобы найти баги. Знак "-" показывает, что от участника ответа нет.
В данном исследовании мы хотели бы изучить следующее:
Мы задали эти вопросы, потому что ответы на них будут полезны для программистов и исследователей в их будущих работах и в улучшении статических анализаторов. Исследования показали, что способ прерывания рабочего процесса разработчика очень важен, поэтому мы хотели бы в частности исследовать и этот вопрос [26], [27]. Интервью были нацелены на опыт обнаружения ошибок разработчиками при использовании статических анализаторов. Изучение опыта разработчиков и наблюдение за тем, как они используют статические анализаторы для поиска ошибок, могут пролить свет на то, почему же эти инструменты не используются в полной мере. Интервью состояли из 3 основных частей: Вопрос-ответ (Раздел III-C), Интерактивное интервью (Раздел III-D) и Проектирование с участием пользователей (Раздел III-E).
В части 1 - Вопрос-Ответ - мы задали разработчикам вопросы, связанные с их общим опытом использования, пониманием и мнением насчет инструментов статического анализа в соответствии с ВИ1. Некоторые вопросы включают в себя:
Вторая часть носит название "Интерактивное интервью". Цель, стоящая за данным интервью - иметь возможность понаблюдать, как разработчики пользуются инструментами статического анализа. Это позволило нам получить более подробную информацию о том, как разработчики используют свои инструменты. Мы стремимся использовать информацию, полученную при ВИ2. Также мы попросили наших участников вслух объяснить, что они делают [28], чтобы мы могли получить хорошее понимание процесса работы и хода их мыслей. Практика интервью для этого исследования дала понять, что интерактивное интервью предоставляет более подробную информацию о том, когда и как разработчики используют свои инструменты статического анализа [25].
Некоторые из вопросов, заданные в ходе этой части:
В целях конфиденциальности, не все из наших участников смогли использовать свои рабочие компьютеры для данной части интервью. В таком случае мы предоставили 6 проектов с открытым исходным кодом на Java, таких как log4j [29] и Ant [30], и попросили каждого участника запустить FindBugs на одном из них. Мы выбрали FindBugs, потому что он является одним из самых популярных и развитых инструментов статического анализа для Eclipse. Из-за технических трудностей наши удаленные участники интервью не смогли в полной мере пройти "интерактивную" часть интервью. Каждому был выдан сценарий использования инструмента статического анализа, и для начала мы попросили пользователей объяснить ход их мыслей. Затем мы задали те же самые вопросы, как если бы мы были в одной комнате.
В последней части интервью мы предложили участникам поучаствовать в улучшении дизайна интерфейса инструментов статического анализа. Мы использовали концепцию проектирования с участием пользователей [31], которая включает в себя заинтересованность участников в процессе проектирования, позволяя им показать, что они хотят, вместо того, чтобы говорить. В целях содействия творчеству каждый участник получил лист бумаги, и мы попросили их показать нам, как они хотели бы, чтобы выглядел инструмент, как он должен работать [25]. Участники не обязались что-либо рисовать, но 6 из них это сделали. Остальные же дали устное описание своих пожеланий касаемо инструмента.
После завершения всех интервью мы вручную разобрали каждое из них. Затем полученные данные были кодированы. Кодирование - это процесс перевода необработанных данных социологического исследования в ту форму, которая может использоваться при подсчетах, делая их быстрее и проще [32]. Мы использовали метод Гордона, чтобы кодировать наши интервью и помочь собрать результаты опроса (Раздел IV). Перед интервью должны быть определены "категории кодирования". Категории должны быть достаточно общими, чтобы подобная информация была сгруппирована вместе, но в то же время они должны быть конкретными. Для этого подхода является нормальным появление "возникающих" категорий после прочтения результатов. Мы разработали и использовали следующие категории кодирования: Производительность инструмента, которая включает в себя все, что связано с результатом работы инструмента (например, ложные срабатывания); Поддержка командной работы включает в себя все, что связано с использованием инструментов статического анализа в команде или совместной настройке; Ввод данных и настройка: в этой категории учитывается особенности настройки в инструментах статического анализа (например, изменение набора правил); Понятность результата включает в себя способность или неспособность понять или интерпретировать результаты, полученные с помощью статического анализа; Рабочие процессы - это категория, которая включает в себя процессы написания, проверки и изменения программного обеспечения разработчиком (например, интеграция инструмента); и Дизайн инструмента - эта категория включают в себя идеи и предложения от наших участников. Примеры каждой из этих категорий ниже:
Результат работы инструмента:
Джейсон: "... как я уже упоминал с Flexnit, он выдает так много предупреждений и их так трудно все просматривать, что когда я смотрю на них, я их тут же забываю"
Ввод данных/Настройка:
Энди: "...это выглядит как список приоритетов, составленный вами, вы знаете, что важно для меня? Нет. Вы знаете? И да, здесь должен быть список приоритетов по умолчанию, потому что текущий не годится"
Поддержка командной работы:
Джон: "Единственная причина, почему мне нравятся результаты, так это из-за возможности общаться, передавать команде чувство прогресса или его отсутствия"
Понятность результата:
Мэтт: "Итак, теперь я хочу знать, почему генерировать исключение типа string - это плохо. Что вместо этого я должен делать? И ни одна подсказка мне не помогает"
Рабочие процессы:
Майк: "Clang самый любимый. Анализ встроен в компилятор. Вы не должны делать что-нибудь специальное для внедрения"
Дизайн инструмента:
Крис: "Я не против того, чтобы источник кода был более пластичным ... допустим в 4 строке есть ошибка ... опустим 5 строку и будем иметь больше контекста, где будут практически все мои комментарии к моему коду"
Следующим шагом в методике Гордона является назначение "символы категории" для каждой категории для более удобного индексирования и обработки информации. Затем Гордон предлагает найти и классифицировать соответствующую информацию, используя категорию символов. В нашей иерархии каждой категории назначен свой собственный цвет в качестве "символа"; если какая-то часть ответов участника относится к одной из категорий, соответствующий текст будет выделен таким же цветом, как и соответствующая категория. Взяв в основу метод Гордона, интервью участника может включать множество категорий и множество данных для одной и той же категории. В целях обеспечения согласованности, один человек был ответственен за разработки категорий, назначению "символа" категории и применение символов к интервью участников. Последний шаг - это проверить надежность кодировок. Для нашего исследования после того, как интервью была построено по методике Гордона, кодировки были переданы другим участникам на рассмотрение. Если бы там были найдены какие-то расхождения, они бы обсуждались и решались в группе, включая в себя те данные, которые могут подходить к нескольким категориям. Для данных интервьюеров, которые подходят более чем к одной категории, создавалась новая, более конкретная категория или "подкатегория". Следует отметить, что целью данных категорий не является задача организовать информацию по актуальности или полезности, также они не должны никак коррелировать с вопросами исследования.
В данном разделе мы обсудим полученные нами результаты. Мы ответили на вопросы исследования, связав их с вопросами категорий кодировки и частями интервью. После анализа результатов мы считаем следующие утверждения верными:
Рис.1. Число участников в каждой категории, выражающее хорошее и плохое впечатление от использования инструментов статического анализа.
Наши интервью показали, что у разработчиков существует множество причин, которые могут подтолкнуть их на использование инструментов статического анализа для поиска багов. Одной из очевидных причин является то, что очень много времени и сил тратится на поиск ошибок вручную. Пять из наших 20 участников считают, что стоит использовать статические анализаторы, так как они могут автоматически искать ошибки в коде. Во время интерактивного интервью Джейсон сказал нам: "всё, что может автоматизировать обычную задачу - круто". Другими словами, одна из причин, по которой стоит использовать инструменты статического анализа - автоматизация поиска багов.
Несмотря на то, что некоторые из наших участников нашли причины использовать статический анализатор, многие высказали противоречивые мнения, которые поставили под сомнение использование статического анализатора.
Tool output. Сообщения инструмента был популярной темой для обсуждения. Из 20 человек, которых мы опросили, 14 выразили негативное отношение к плохо представленному результату. Инструменты статического анализа, как известно, порождают ложные срабатывания, и эти ложные срабатывания могут "перевесить" правильные по количеству [33]. Другой известный факт, особенно касаемо больших проектов - количество предупреждений, выдаваемых анализатором. Оно может быть высоко, иногда исчисляется даже тысячами [9]. Некоторые из наших участников предположили, что ложные срабатывания и большое количество предупреждений будут менее обременительными в случае, если способ вывода данных будет более понятным и ясным. Коди, который любит использовать Dehydra, почувствовал разочарование, потому что результаты сбрасываются в единый список, и требуется много времени, чтобы разобраться, что нужно выполнить. Джейсон хочет, чтобы в выводе данных был участок, который указывает на проблему, что с ней стоит сделать, чтобы быстрее оценить, что является важным или неважным. Эта часть также должна показывать, используя иерархию вызовов, какие ошибки от чего зависят. Во время интерактивного интервью он прокомментировал предыдущий опыт работы с FindBugs. У него был большой список предупреждений без дополнительной информации о проблеме. "Пролистывание всего хлама" быстро его утомляло. Может быть, это стоит рассмотреть, как пример для улучшения вывода данных.
Совместная работа. Очень часто результат работы зависит от умения работать в команде. Для 9 наших участников, недостаток или слабая поддержка командной работы и сотрудничества является одной из причин, почему команды, так же как и индивидуальные разработчики, не могут разобраться или регулярно пользоваться инструментами статического анализа. По словам Джона, инструменты статического анализа полезны в попытке соблюдения стандартов кодирования, нет проще способа поделиться настройками с другими людьми в команде, что представляется рутиной, особенно в том случае, когда стандарты должны быть изменены. Многие из наших участников изъявили желание общаться и переговариваться при использовании инструмента статического анализа, особенно в команде. Таким образом, статические анализаторы могут быть полезны в командной работе, но существующие инструменты недостаточно справляются с этой задачей. Более новые версии FindBugs предлагают функцию облачного хранилища, которое может быть использовано для хранения, обмена и обсуждения предупреждений [34]. Хотя такая функция способствует более удобной коммуникации и обмену предупреждениями анализатора между разработчиками, также она позволяет добавлять комментарии к багу или добавить оценку, для этого необходимо использовать браузер. Это отвлекает разработчика от процесса разработки, который снижает желание проверять код, когда это необходимо.
Настройка. Для 17 наших участников настройка играет важную роль, однако много инструментов сложно настроить, и они не включают в себя настройки, необходимые разработчикам. Ложные срабатывания и большие объемы предупреждений являются хорошо известными недостатками, которые отталкивают от использования инструментов статического анализа. Однако Фрэнк сказал, что настройка инструмента играет огромную роль в конечном результате. Джон заявил в интервью, что многие инструменты так сложно настроить, что это сильно мешает. "Иногда сложно даже добраться до меню, где находятся параметры настройки конкретной функции", - поддерживают Мэтт и Джош. Один из наших участников, Джейк, оказался в интересном положении во время его интерактивного интервью, где он не мог настроить инструмент. Правда затем он полез в Интернет, чтобы разобраться, где находится меню настроек. Общая проблема, с которой столкнулось большинство участников, это неспособность выключать или скрывать некоторые предупреждения. В некоторых инструментах статического анализа есть функция отключения некоторых уведомлений, ведь не всем разработчикам удобно работать с абсолютно отключенными уведомлениями. Например, Мэтт боится, что забудет их включить обратно. Отключение или игнорирование может быть неправильным; как отметил Джордан, он бы хотел, чтобы в инструментах статического анализа можно было добавлять оценки к предупреждениям. Более сложные решения могут включать в себя добавление условия срабатывания, например, "это предупреждение не является сейчас проблемой, если в будущем будут выполнены следующие условия..."
Понятность результата. Основной задачей использования такого инструмента, как FindBugs, является поиск багов. Разработчик не может понять, как инструмент пытается ему донести, какие существуют баги в коде. 19 из 20 участников чувствовали, что многие инструменты статического анализа не предоставляют информацию об ошибках с достаточной детальностью, например, в чем она заключается и как ее исправить. Джеймс в интервью сказал нам: "Одно дело, когда выдаётся сообщение об ошибке, и совсем другое дело, когда выдается нужное сообщение об ошибке". В разговоре о плагинах Python на платформе Eclipse, он также заявил: "Я считаю, что информация, которую они предоставляют, недостаточно полезна, поэтому я предпочитаю её игнорировать". Несколько участников высказали мнение, что было бы полезно иметь ссылки на более подробную информацию или примеры в отчетах об ошибках. В некоторых ситуациях требуется больше информации, чтобы понять, в чем состоит проблема и почему таковой она является; понимание, почему какой-то недочет является ошибкой, может помочь разработчику лучше оценить, нет ли ложного срабатывания и попытаться избежать повторения такой же проблемы. Райан сказал нам во время своего интерактивного интервью, что инструмент должен использовать "реальные слова", или более естественный язык для объяснения проблемы.
Наиболее часто встречается сложность, когда использование статического анализатора недопустимо или неэффективно для быстрого исправления багов. Большинство наших участников выразили заинтересованность в использовании данного инструмента, чтобы посмотреть на предложения или быстрые решения к коду. Эбби заявил: "Если вы сможете сказать мне, что это ошибка, то вы должны быть в состоянии её исправить". Джордан абсолютно с этим согласен; он любит инструменты, которые быстро находят решения. Исходя из наших интервью, данные исправления не должны быть автоматическими; некоторые хотели бы, чтобы в коде были представлены примеры, как можно исправить данную ошибку. Некоторые участники выразили скептическое отношение относительно быстрого исправления багов в инструментах статического анализа. Например, во время интерактивного интервью Джордан заметил, что при использовании нескольких инструментов, они могут иметь противоречивые быстрые исправления или решения. В последнем опыте Фрэнка с автоматическим изменением кода, ему пришлось вручную проводить рефакторинг, потому что автоматически что-то было сделано неверно. Поэтому он предпочитает использовать поиск и делать собственные изменения. Другой участник, Адам, был обеспокоен тем фактом, будет ли сохранена семантика его кода после быстрого исправления ошибок. На текущий момент большинство статических анализаторов с возможностью внесения быстрых исправлений в код не позволяют быстро понять, что было изменено в коде после применения быстрого исправления. Практически все наши участники согласились, что хорошо продуманное исправление ошибок, может помочь им лучше понимать, о какой ошибке ведет речь анализатор, что приведет к лучшей производительности разработчика.
Наиболее популярная тема во время интервью - "интеграция анализатора в среду разработки". Иногда процесс разработки включает в себя запуск инструмента статического анализа, но чаще всего анализатор не запускается в середине работы с каким-то определенным кодом или специфичным заданием. Разработчик обычно запускает анализатор в случае обнаружения какой-то проблемы. [19]. Анализ наших интервью показывает, что, несмотря на вышесказанное, разработчики могут захотеть использовать анализатор по-другому в их рабочем процессе. Например, некоторые разработчики предпочитают, чтобы инструмент запускался в фоновом режиме, так как им проще разобраться, в чем ошибка, без прерывания на запуск анализатора. С другой стороны, некоторые разработчики не используют интегрированные среды разработки, но если им требуется использовать инструмент статического анализа, то интеграция с компилятором очень важна. Девятнадцать из 20 опрошенных разработчиков, выразили мнение о важности процесса интеграции и того, как она должна быть выполнена.
Некоторые наши участники нашли несколько фич в статическом анализаторе, использование которых помогло лучше интегрировать анализатор в рабочий процесс, тем самым увеличив его использование. Например, Джон понимает, что инструменты статического анализа могут быть использованы, чтобы помочь организовать рабочий процесс, основываясь на производимых анализатором результатах. Приведем конкретный пример: если вы работаете с инструментом статического анализа своего кода впервые, он будет полезен в поиске багов; это может дать представление о том, насколько подробна информация, выдаваемая анализатором, а также о том, когда вам лучше следует его запустить. Из всех инструментов, которые Адам использовал в последнее время, ему больше всего понравился IntelliJ и его всторенный статический анализатор. Он тесно интегрируется со средой и кажется, что анализ происходит в режиме реального времени. Для этих участников, как и для нескольких еще, интеграция со средой разработки играет важную роль в решении начать использовать или продолжать использование инструмента статического анализа. Распространенные самостоятельные инструменты статического анализа, такие как FindBugs и PMD, имеют возможность интеграции с такими средами разработки, как Eclipse, NetBeans, что становится особенно важно, когда вы используете больше, чем один инструмент статического анализа одновременно. Это мы узнали из обсуждения со Стивом его последнего опыта работы, где он использует сразу 3 разных статических анализатора. Джордану и Крису понравилось, как FindBugs, PMD и CheckStyle вписываются в их процесс разработки. Для Джордана это неотъемлемая часть его рабочего процесса. Однако, для большинства наших участников, настоящие инструменты статического анализа недостаточно эффективно интегрируются в их процесс разработки.
Одна из самых больших демотивационных сил, возлагаемых на разработчика, когда дело доходит до использования инструмента статического анализа - "непересекающийся процесс", как называет это Тони. Многим нашим участникам, особенно тем, которые не используют интегрированные среды разработки, не нравится, когда они должны выйти из их среды кодирования, чтобы использовать инструмент или посмотреть результаты, выданные анализатором. Например, Фрэнк, Ли, Джеймс и Энди прокомментировали, как "болезненно" было во время интерактивного интервью переключать режимы в FindBugs, чтобы исследовать полный список ошибок. По словам Ли, необходимость открыть другой режим, чтобы узнать, что происходит, является гарантией, что немотивированные люди не будут этого делать. Для Фрэнка удобно, что результаты спрятаны, так что вы не перегружены информацией, имея возможность вернуться и развернуть окно, где можете посмотреть ошибки, требующие дополнительного усердия. Другие инструменты, которые получили подобные жалобы, это Coverity и Lint для C/C++ проектов. Для Райана и Тони самым большим недостатком использования Coverity является то, что он не способен интегрироваться в их среду кодирования, что приводит к большому количеству нажатий туда и обратно между окнами редактора и статическим анализатором. Филу не нравится использовать Lint, потому что он должен "усердно постараться", чтобы его использовать.
Некоторые наши участники прояснили, что даже если инструмент интегрируется с их средой разработки, то, возможно, он не будет хорошо интегрироваться в их процесс. Например, один из наших участников, Майк, не использует интегрированную среду разработки, поэтому инструмент, хорошо вписывающийся в эту среду, не подходит для его процесса разработки. Ему нравится использовать Clang, потому что анализ встроен в компилятор, который не "требует" среды. По словам Гордона, одной из ключевых проблем со средствами статического анализа является то, что время от времени они могут мешать его продуктивности. Один из вариантов, как может быть сделано, что инструмент замедляет разработчика, занимая много времени на запуск, что является частой жалобой среди наших участников. Из опыта Джейсона: "если это замедляет твой процесс работы, то не стоит это использовать". Заявление Джейсона похоже на правду, как и Стива, который использовал различные инструменты, но FindBugs ему не понравился потому, что он работал медленнее, даже несмотря на то, что он мог интегрироваться в его среду разработки. IntelliJ, который содержит встроенные статические анализаторы, в попытке предотвратить проблему прерывания рабочего процесса разработчика, использует время простоя для сообщения об ошибке, но Мэтт все равно это считает надоедливым. Джейсон считает, что проблема с текущими инструментами статического анализа заключается в том, что они не могут работать с большими базами кода, что приводит к разрыву его "потока разработки".
С точки зрения процесса, участники оценили возможность статического анализа как для быстрого нахождения ошибок, при появлении в тексте программы, так и после, в процессе разработки. С точки зрения рабочего процесса, очень важно исправлять потенциальные ошибки на стадии, когда они только появились, потому что необходимый контекст, чтобы понять ошибку, уже находится в рабочей памяти разработчиков. Наоборот, если разработчик проверяет код "апосля", то ему требуется вспомнить контекст, чтобы понять ошибку, что может вызвать трудности. Это похоже на контраст между "потоком рефакторинга" и "медленным рефакторингом", где первый включает код реструктуризации, с которым он работал, а последний включает в себя сам рефакторинг, находя "худший код" и имея дело сперва с ним [35]. Медленный рефакторинг - это унылая практика, и ее аналог в статическом анализе - найти наиболее серьезные предупреждения статического анализатора во всей кодовой базе и иметь дело сперва с ними. Такая практика может не привести к желаемым результатам. Исследования показали, что большое количество предупреждений статического анализатора в рабочих системах, совсем не обязательно приводит к программным сбоям. [9].
Нашей главной целью исследования является улучшение инструмента статического анализа. Лучший способ сделать это - узнать, как хотят, чтобы выглядел инструмент. Большинство предложенных вариантов дизайна приходятся на предупреждения, уведомления или окно быстрого исправления ошибок (англ.- quick fix). Участники сделали несколько других интересных предложений, которые также будут представлены.
Дизайн окна быстрого исправления. Десять из наших участников предположили, как должны выглядеть окна быстрого исправления. Большинство наших участников хотели, чтобы у них была возможность просматривать исправления, прежде чем их применять, чтобы посмотреть, как они изменят код. Эбби и Тони предлагают разделить редактор кода, чтобы была возможность показать выделением различия в коде, то, как он изменился, что добавилось. Хотелось бы, чтобы с одной стороны был показан код, а с другой показывалось, как он изменился. Некоторые участники считают, что нужно показывать новый код перед его применением и только затем в ручном режиме его применять, чтобы быть точно уверенными, что исправление не приведет к новым проблемам. Один из участников, Майк, предпочитает не пользоваться функцией быстрого исправления, потому что предупреждений об ошибке достаточно.
Одна интересная задумка насчет окна быстрого исправления пришла от Райана во время его интерактивного интервью. Он предложил показывать диалоговое окно с тремя вариантами выбора во время применения быстрого исправления. Чтобы вызвать это окно и исправить ошибку, достаточно кликнуть, и появится три варианта: применить полное исправление (опция по умолчанию), не применять исправления или применять постепенно, позволяя разработчику выбрать какую часть изменений сохранить. Инструменты статического анализа, такие как FindBugs и InteliJ, предлагают некоторые исправления. Но они не дают полностью просмотреть контекст, в котором применено исправление, что порождает сомнения в правильности и необходимости данного действия.
Предупреждения и их интерфейс. Все 20 участников нашего исследования сказали нам, когда и как они хотели бы, чтобы появлялись предупреждения об ошибке в их коде. Главным критерием была быстрота. Разработчики хотят, чтобы была быстрая обратная связь между ними и инструментом, которая не будет мешать их рабочему процессу. Для некоторых наших участников это означало запустить инструмент на фоне IDE, чтобы была возможность обратиться к нему, как только будет обнаружена ошибка. Для других участников это означало запуск инструмента во время написания или компиляции кода. Таким образом, результаты представляются, когда разработчик остановился в процессе разработки[19]. В целом, наши участники считают представленный инструмент статического анализа недостаточно быстрым; эта быстрота должна быть согласована с мыслительным процессом разработчика, чтобы не навредить процессу разработки.
Наши участники также считают, что было бы полезно иметь возможность быстрой оценки ошибок, таких как откладывание уведомления, чтобы посмотреть позже, сохранение и возможность поделиться своей находкой с другими разработчиками. Многие из наших участников предположили, что инструменты статического анализа должны позволить разработчикам игнорировать определенные ошибки и отправлять их в хранилище для дальнейшего рассмотрения. Большинство инструментов, если они позволяют разработчику игнорировать конкретные предупреждения, позволяют выключить или отключить определенную категорию ошибок для конкретной линии кода, используя комментарий, который, как Гордон сказал нам, делает код "пахнущим". Разработчики хотели бы иметь функцию игнорирования каждой единичной ошибки в случае, если они не хотят её исправлять, снова видеть или хотят отложить её на определенное время, чтобы позже к ней вернуться.
Другие идеи интерфейса. Наши участники также пришли с творческими идеями. Один из участников, Крис, предложил, чтобы редактор был более "пластичный". Когда выдается предупреждение об ошибке, и он хочет получить больше информации, инструмент должен поместить код, к которому относится предупреждение, в редактор. Пара наших участников полагала, что было бы классно иметь круглую диаграмму ("в виде пирога") для удобной визуализации ошибок, вместо стандартного списка. Это сделает переход между кодом и предупреждением проще. Во время совместного проектирования дизайна Фрэнк предложил возможное решение - чтобы общая картинка проекта была в качестве "тепловой карты". Тепловая карта будет использовать цвета, чтобы показать, где находятся ошибки, насколько они серьезны. Было бы хорошо начать с общего вида проекта, где можно увидеть детализировано ошибку на каждом уровне, понять, на какую часть проекта стоит обратить внимание. Это похоже на концепцию Ху в инструменте Path Projection, предназначенного для визуализации выходных данных, которые часто, если не всегда, представляются в текстовом формате и сложны для понимания [11].
Еще одну интересную идею представили нам пара участников. Они предложили в зависимости от серьезности ошибки использовать не разные цвета для обозначения, а градиент одного цвета: чем светлее оттенок, тем серьезнее ошибка. На рисунке 2 изображена идея Мэтта, он назвал сторону редактора "Градиент" (А), где он хотел бы видеть важность. В верхнем правом углу Мэтт также перечислил цвета, которые используются в текущем инструменте (B). Например, "R" означает красный. Идея не нова - другие исследования тоже заняты вопросом цвета для обозначения степени ошибок [36], [37].
Рис.2. Один из наших участников совместного проектирования, Мэтт; (А) показывает, где Мэтт хочет, чтобы был градиент, и (В) показывает, каким способом данный инструмент сообщает о серьезности ошибок.
Есть несколько угроз для достоверности нашего исследования: здесь мы классифицируем внешние, внутренние и конструктивные угрозы.
Внешняя. Одним из признаков для обобщения нашего исследования служит размер выборки. Мы получили ценную информацию из 20 интервью. Из-за временных ограничений (занятости разработчиков), они не могут быть показательными для большинства людей, которые используют инструменты статического анализа. Нам бы хотелось опросить больше людей, чтобы сделать анализ более точным. В исследовании, проведенном Лайманом и другими [19], которое мы обсуждали ранее, использовался похожий метод, участвовало похожее количество человек (18). Другая возможная угроза — это то, что мы опросили разработчиков, которые уже пользовались инструментом статического анализа. Возможно, что инструменты статического анализа недостаточно используются из-за нехватки знаний. Также стоит отметить, что некоторые наши участники уже имели опыт работы с инструментами статического анализа, что не исключает некую предвзятость мнения.
Внутренние. Еще одна угроза для проведения интерактивного интервью - то, что в некоторых случаях мы проводили его удаленно. Мы недостаточно подготовились к тому, что техника может не работать должным образом или будет недоступна. Интерактивное интервью и совместное проектирование проводились иначе, чем совместные интервью. Несмотря на это, результаты опроса удаленных участников по-прежнему оценивались: они могли дать полезную информацию, полагаясь на свой предыдущий опыт. Только 2 из участников интервью попали в эту категорию, так что вряд ли это сильно повлияет на результаты.
Концепция. Целью интерактивного интервью было получить больше точной информации о том, как разработчики используют свои инструменты. Одним из ограничений является то, что некоторые разработчики не были знакомы с кодом или окружающей средой, которыми они пользовались во время наших интервью, вместо использования своего кода в своей собственной среде разработки. Это могло стать причиной того, что некоторые разработчики вели себя не так, как в своей среде разработки. В идеале было бы лучше, если бы мы могли пронаблюдать за их работой в своей среде разработки; но в целях конфиденциальности нам не разрешили просматривать проприетарный код. В целях компенсации этого мы использовали хорошо известный открытый исходный код проектов. Еще одна угроза для нашей работы состоит в том, что мы не продумали сценарий прохождения данного этапа интервью, который помог избежать непреднамеренных "подсказок" нашим участникам. Одним из примеров может послужить изложение целей исследования в каждом начале интервью. Это могло привести к тому, что участники пытались угадать и говорить то, что хотят от них услышать [38]. Нам кажется, что мы смогли смягчить этот негативный эффект, спрашивая участников об их прошлом опыте.
Из наших интервью можно сделать несколько выводов для нынешних и будущих статических анализаторов. Текущие инструменты статического анализа не могут предоставить достаточно информации для разработчиков, например, что делать с предупреждениями, и очень редко предлагают исправить код, в котором, как анализатор полагает, есть проблема. Если бы статические анализаторы предлагали варианты быстрого исправления проблем и давали разработчику возможность применить исправление к ней, это могло бы помочь им понять суть проблемы быстрее, значительно сэкономив время и усилия. Наши результаты показывают, что FindBugs был бы более полезен, если бы имел более информативные сообщения и предложения о том, как быстро исправить ошибки. В то же время, быстрые исправления - не универсальный механизм помощи разработчикам, потому что многие предупреждения анализатора не могут быть разрешены с помощью небольшого количества вариантов решения. Например, FindBugs предупреждает разработчиков, когда два названия метода в том же классе различаются только при помощи написания. Отсутствие быстрого исправления удовлетворит разработчика в этом случае. Вместо быстрого исправления подойдут интерактивные быстрые исправления, которые предоставляют легкий доступ к рефакторингу и модификации кода, могут полуавтоматически помочь разработчикам решить такие предупреждения анализатора. К сожалению, быстрые исправления могут привести к поспешным исправлениям в коде, которые потенциально могут привести к большим проблемам, например, появлению новых ошибок. Также существуют проблемы с реализацией удобного интерфейса быстрых исправлений. Мы еще не исследовали, что это за аспекты и как их решать, так как они выходят за рамки этой работы.
Разработчикам нравятся инструменты IntelliJ и FindBugs, потому что у них есть возможность запускаться автоматически без дополнительных команд разработчика. Однако вопрос предоставления информации, которую разработчики нашли бы полезной, остается открытым. Одним из способов, чтобы позволить разработчикам сосредоточиться на оценке степени серьезности ошибки, является рассмотрение предупреждения, как задачи в Mylyn [39]. В Mylyn правила, соблюдение которых проверяется, чтобы сделать оценку, автоматически помещаются в лист с предупреждениями task-context. Например, предупреждение о присвоении переменной нулевого указателя. Таким образом, посторонние предупреждения и программные элементы, не связанные с предупреждением, могут быть автоматически опущены. С помощью Mylyn оценка проблемы и ее контекста может быть сохранена и передана другим разработчикам, что позволяет быстро поделиться знаниями о найденных проблемах.
Разработчики предпочитают инструмент, использование которого легко внедряется в их рабочий процесс. Например, если разработчик должен отправить свой код в репозиторий много раз за день, то он, скорее всего, будет использовать инструменты статического анализа каждый раз, прежде чем заложить свой код. Таким образом, если инструмент предусматривает такой рабочий процесс, то разработчику будет просто его использовать. Разработчики также не против таких функций, как способность изменять существующие предупреждения или наборы правил, выбрать, когда и как должен запускаться инструмент. Большинство инструментов статического анализа для поиска багов сегодня дают возможность настроить анализатор. Например, в FindBugs и IntelliJ можно выключить предупреждения или просто отключить их для любой из категорий ошибок, которые находит инструмент. Если инструмент предусматривает такой рабочий процесс, то разработчику будет просто его использовать. Программа FindBugs позволяет разработчикам отключить определенные детекторы ошибок, но только на уровне проекта. Выключение детектора для конкретного класса или файла должно быть сделано вручную на каждой строке кода, которую вы хотите проигнорировать. Настройка, которая требует больших усилий, в конце концов может привести к отказу от использования инструмента.
Результаты нашего исследования показывают, что есть способы, чтобы сделать инструменты статического анализа более полезными для разработчиков. В будущем, возможно, будет необходимо выполнить последующие исследования, которые сфокусируются на использовании статических анализаторов. Это необходимо, чтобы дать более целостное представление о факторах, которыми руководствуются разработчики, выбирая, использовать статический анализатор или нет. Мы приступили к реализации прототипа статического анализатора, основанного на результатах, полученных в этом исследовании. Одной из основных фич, на которой мы собираемся сфокусироваться, - это возможность исправить найденную проблему. Точнее, мы заинтересованы в реализации возможности интерактивных "быстрых" исправлений, давая разработчику больше контроля над "автоматическими исправлениями". Мы также планируем провести исследование нашего прототипа среди разработчиков ПО с различным опытом работы.
В этой статье мы исследовали, почему разработчики не широко используют статический анализ, и то, как существующие инструменты могут быть улучшены, чтобы расширить их использование. Мы провели исследование с участием 20 разработчиков ПО, которые в среднем имеют 10-летний опыт работы со статическим анализатором ошибок. Мы также обсудили выводы наших результатов.
Наши результаты подтвердили, что ложные срабатывания и перегруженность разработчика играют важную роль в неудовлетворенности нынешними статическими анализаторами. Каждый из факторов, представленный в этой статье, должен быть учтен при реализации инструмента, который приведет к более широкому использованию инструментов статического анализа для улучшения качества программного кода и поддержанию стандартов кодирования. Будущие статические анализаторы можно улучшить путем улучшения командной работы разработчиков, улучшения интеграции инструмента в процессы разработки, предоставив детальное объяснение ошибок с автоматическим исправлением, а также включив в себя легкие и полезные опции конфигурации для инструмента.
Мы бы хотели поблагодарить Нат Айевах и наших участников за их вклад. Этот материал основан на работе, при поддержке Национального научного фонда под грантом No. 1217700 и Google Faculty Award.
[1] L. C. Briand, W. M. Thomas, and C. J. Hetmanski, "Modeling and managing risk early in software development," in Proc. ICSE, 1993, pp. 55-65.
[2] N. Nagappan and T. Ball, "Static analysis tools as early indicators of pre-release defect density," in Proc. ICSE, 2005, pp. 580-586.
[3] M. Gegick and L. Williams, "Towards the use of automated static analysis alerts for early identification of vulnerability- and attack-prone components," in Proc. ICIMP, 2007, pp. 18-23.
[4] "IntelliJ IDEA," https://www.jetbrains.com/idea/.
[5] "FindBugs," http://findbugs.sourceforge.net/.
[6] N. Ayewah, D. Hovemeyer, J. D. Morgenthaler, J. Penix, and W. Pugh, "Using Static Analysis to Find Bugs," IEEE Softw., vol. 25, no. 5, pp. 22-29, 2008.
[7] "Eclipse," http://www.eclipse.org/.
[8] "NetBeans," http://www.netbeans.org/.
[9] N. Ayewah and W. Pugh, "The Google FindBugs Fixit," in Proc. ISSTA, 2010, pp. 241-252.
[10] A. Bessey, D. Engler, K. Block, B. Chelf, A. Chou, B. Fulton, S. Hallem, C. Henri-Gros, A. Kamsky, and S. McPeak, "A Few Billion Lines of Code Later: Using Static Analysis to Find Bugs in the Real World," Commun. ACM, vol. 53, no. 2, pp. 66-75, 2010.
[11] Y. P. Khoo, J. S. Foster, M. Hicks, and V. Sazawal, "Path projection for user-centered static analysis tools," in Proc. PASTE, 2008, pp. 57-63.
[12] S. C. Johnson, "Lint, a C Program Checker," Bell Laboratories, Tech. Rep., 1978.
[13] "PMD," http://pmd.sourceforge.net/.
[14] B. Chess and J. West, Secure Programming with Static Analysis. Addison-Wesley Professional, 2007. [15] K. Vorobyov and P. Krishna, "Comparing Model Checking and Static Program Analysis: A Case Study in Error Detection Approaches," in Proc. SSV, 2010, pp. 1-7.
[16] M. Dastani, "The role of visual perception in data visualization," Journal of Visual Languages and Computing, vol. 13, no. 6, pp. 601-622, 2002.
[17] N. Ayewah and W. Pugh, "A report on a survey and study of static analysis users," in Proc. DEFECTS, 2008, pp. 1-5.
[18] S. Heckman and L. Williams, "On Establishing a Benchmark for Evaluating Static Analysis Alert Prioritization and Classification Techniques," in Proc. ESEM, 2008, pp. 41-50.
[19] L. Layman, L. Williams, and R. St. Amant, "Toward reducing fault fix time: Understanding developer behavior for the design of automated fault detection tools," in Proc. ESEM, 2007, pp. 176-185.
[20] "Jtest," http://www.parasoft.com/jsp/products/jtest.jsp.
[21] "Klocwork Insight," http://www.klocwork.com/products/insight.
[22] "Microsoft Visual Studio," http://www.microsoft.com/visualstudio/.
[23] "Google CodePro AnalytiX," http://code.google.com/javadevtools/.
[24] S. Hove and B. Anda, "Experiences from Conducting Semi-structured Interviews in Empirical Software Engineering Research," in Proc. METRICS, 2005, pp. 1-10.
[25] B. Johnson, "A Study on Improving Static Analysis Tools: Why are we not using them?" in Proc. ICSE, Student Research Competition, 2012.
[26] T. Robertson, S. Prabhakararao, M. Burnett, C. Cook, J. Ruthruff, L. Beckwith, and A. Phalgune, "Impact of interruption style on enduser debugging," in Proc. CHI, 2004, pp. 287-294.
[27] J. Gluck, A. Bunt, and J. McGrenere, "Impact of interruption style on end-user debugging," in Proc. CHI, 2007, pp. 41-50.
[28] C. H. Lewis, "Using the "Thinking Aloud" Method In Cognitive Interface Design," IBM, Tech. Rep. RC-9265, 1982.
[29] "log4j," http://logging.apache.org/log4j/.
[30] "ANT," http://ant.apache.org/.
[31] C. Spinuzzi, "The Methodology of Participatory Design," Technical Commun., vol. 52, no. 2, pp. 163-174, 2005.
[32] R. Gordon, "Coding interview responses," in Basic Interviewing Skills. Waveland Pr Inc., 1998, pp. 183-199.
[33] H. Shen, J. Fang, and J. Zhao, "EFindBugs: Effective error ranking for findbugs," in Proc. ICST, 2011, pp. 299-308.
[34] "FindBugs Cloud Storage," http://findbugs.sourceforge.net/findbugs2. html#cloud.
[35] E. Murphy-Hill and A. P. Black, "Refactoring Tools: Fitness for Purpose," IEEE Softw., vol. 25, no. 5, pp. 38-44, 2008.
[36] B. Oberg and D. Notkin, "Error reporting with graduated color," IEEE Softw., vol. 9, no. 6, pp. 33-38, 1992.
[37] E. Murphy-Hill and A. P. Black, "An Interactive Ambient Visualization for Code Smells," in Proc. SoftVis, 2010, pp. 5-14.
[38] "Threats to Construct Validity," http://www.socialresearchmethods.net/ kb/consthre.php. [39] M. Kersten and G. C. Murphy, "Mylar: a degree-of-interest model for IDEs," in Proc. AOSD, 2005, pp. 159-168.
Разрабатывая анализатор PVS-Studio, мы учитывали, как свой собственный опыт работы со статическими анализаторами кода, так и сторонние мнения. В том числе, мы видели и читали эту статью. Она оказала воздействие на интерфейсные решения, положенные в основу анализатора кода PVS-Studio. И мы выражаем за это благодарность автором этой статьи. Спасибо!
Познакомиться с анализатором кода PVS-Studio и его интерфейсом можно, обратившись к статье "PVS-Studio для Visual C++". Здесь мы только совсем кратко опишем, как те или иные проблемные вопросы, описанные в статье, решались в нашем анализаторе.
