Статический анализ кода - это эффективный инструмент, позволяющий получить хорошее представление о качестве кода проекта и уметь прогнозировать потенциальные проблемы, которые могут возникнуть. Термин «качество кода» в целом немного расплывчатый, но в нашем контексте мы можем понимать качество кода как все, что связано с согласованностью кода, удобочитаемостью, производительностью, охватом тестирования, уязвимостями ...

Этот анализ может легко выявить области кода, которые можно улучшить с точки зрения качества, и, что еще лучше, мы можем интегрировать этот анализ в рабочий процесс разработки и, таким образом, решать эти проблемы качества кода на ранних этапах разработки, даже до того, как они появятся. добраться до основных ветвей.

Идея состоит в том, чтобы добавить еще один этап в наш процесс непрерывной интеграции, поэтому каждый раз, когда мы хотим объединить новый код в основной ветке с помощью запроса на извлечение, наш CI-сервер (или сторонняя служба) будет запускать этот анализ качества кода, устанавливая результат в запрос на вытягивание и сделать его доступным для коммитера и рецензентов кода.

На этом этапе мы могли бы определить цели по качеству кода для каждого проекта, которые, если они не достигнуты, помечаются как «непринятые». Эти цели должны быть установлены и согласованы всеми участниками разработки (разработчиками, командой QA, менеджером проекта…). Например, мы могли бы определить, что новый код должен иметь не менее 80% тестового покрытия и не иметь проблем с качеством кода, в противном случае запрос на вытягивание не будет успешным (не поймите меня неправильно, неудачный не означает отклоненный, но рецензенты кода должны учитывать этот анализ во время принятия решения, одобряют ли они запрос на слияние). И все это автоматизировано!

Кроме того, этот анализ вводит точку зрения объективности в процессе проверки кода, сокращая количество комментариев и обсуждений между разработчиками и, таким образом, время, затрачиваемое на проверку кода.

Инструменты автоматической проверки кода

Итак, объяснив, как происходит процесс Постоянного качества кода, нам нужно выбрать инструмент, отвечающий за выполнение анализа на основе набора правил и пороговых значений. Следует отметить, что эти инструменты не запускают ваши тесты, поэтому тестовое покрытие должно предоставляться извне, что означает, что вы должны запускать свои тесты (обычно на вашем CI-сервере) и отправлять покрытие, предоставленное вашим тестовым репортером, в ожидаемый формат (например, lcov для Javascript).

В течение нескольких дней я тестировал наиболее известные «инструменты автоматической проверки кода» (так они называются) и расскажу вам о моем личном опыте использования каждого из них, а также о достоинствах и недостатках, которые я обнаружил. Но прежде чем углубиться в это, я хотел бы описать требования, которые мы искали в нашей компании (очевидно, они, вероятно, не такие, как у вас).

Наши основные требования:

  • Полная поддержка Javascript, поскольку это основной язык программирования в наших проектах. Наш основной стек - это NodeJS в бэкэнде, а во фронтенде мы используем Angular для старых проектов и React / Vue.js для новых (в зависимости от конкретного проекта).
  • Интеграция с Bitbucket Cloud (наша служба VCS) для добавления встроенных комментариев и проверок качества кода в запросы на извлечение
  • Хороший статический анализ кода с обширным набором правил.
  • Размещено в облаке. Мы хотим сосредоточиться на разработке программного обеспечения и
    не тратить время на обслуживание сервера / инструмента.
  • Определите цели качества кода и настройте пороги для каждого показателя качества кода (например, охват тестированием более 80%, не более одной критической проблемы)
  • Хорошо задокументировано

Приятно иметь

  • Простая интеграция с Codeship (наш сервис CI)
  • Интеграция с IDE / текстовыми редакторами
  • Горячие точки. Простой способ найти места, на которых мы должны сосредоточиться, потому что они потенциально являются источником ошибок
  • Библиотека для удобной загрузки результатов тестового покрытия

Кодекс климата

Не знаю, я ли это, но в последнее время, когда я проверяю репозитории Github библиотек / фреймворков, которые мы используем, я часто вижу на них значок Code Climate.

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

Ремонтопригодность оценивается от A до F по различным параметрам (в основном, по количеству запахов кода и дублированию кода).
Охват тестами также оценивается от A до F в зависимости от общего процента.

Изначально анализ кода не слишком точен, когда вы запускаете анализ в первый раз. По крайней мере, в Javascript ... Например, он не отличает нормальную функцию от фабричной функции (способ создания новых объектов в Javascript с помощью функций), поэтому он дает много «ложноположительных» ошибок, утверждающих, что фабричная функция превышает максимальное количество строк кода, поскольку он считает это «нормальной» функцией (нет возможности исключить фабричные функции из этой проверки и оставить ее для остальных функций, или, по крайней мере, я ее не нашел).

По умолчанию в нем не больше правил, чем правила, связанные со сложностью (количество методов, длина файла, когнитивная сложность и т. Д.) И дублированным кодом. Несмотря на то, что вы можете добавить больше плагинов анализа с большим количеством правил, чем те, которые предоставлены из коробки, стоит упомянуть, что для Javascript, в частности, единственными двумя движками являются ESLint и Node Security, а поскольку ESLint - это то, что вы можете легко интегрировать в свой рабочий процесс и проверять через свой CI-сервер, я бы не стал рассматривать это как актив в Code Climate.

Что касается покрытия тестированием, он довольно хорошо отображает покрытие для каждого файла, и вы даже можете отсортировать их, поэтому легко увидеть, какие файлы имеют плохое покрытие тестированием.

Он также предоставляет различные диаграммы, которые показывают тенденции в вашем коде (например, если технический долг увеличивается / уменьшается, тестовое покрытие увеличивается / уменьшается). Я бы отметил тот, который сопоставляет поддерживаемость с оттоком (файлы, которые часто меняются). Файлы в правом верхнем углу, то есть файлы с высоким техническим долгом и высокой частотой изменений, с большей вероятностью будут генерировать ошибки.

В нем говорится, что есть интеграция с несколькими IDE / текстовыми редакторами, такими как Atom, Vim, но я не тестировал.

Следует отметить, что он не имеет интеграции с BitBucket Cloud для запросов на извлечение, поэтому было бы здорово, если бы команда Code Climate предоставила эту функцию в ближайшем будущем.

Кроме того, он предоставляет библиотеку под названием cc-test-reporter f, которая позволяет загружать результаты покрытия вашего теста. Это просто и удобно. Работает как часы.

Codebeat

Этот инструмент использует подход, очень похожий на Codeclimate, с точки зрения оценки проектов. Основное отличие заключается в том, что Codebeat использует систему «шкалы 4,0» вместо оценок от A до F.

Codebeat использует свой собственный алгоритм для анализа сложности (вместо него Code Climate использует хорошо известные движки), и я бы сказал, что по умолчанию он работает довольно хорошо.

Примерами того, что анализируется в дополнение к обычным, таким как количество функций, общее количество строк кода и т. Д., Являются:

  • Глубина вложения блоков, что обычно означает очень сложные функции.
  • Арность (количество аргументов) функций.
  • Цикломатическая сложность
  • Количество возвратов внутри функции
  • Условие перехода по назначению (ABC), которое учитывает количество назначений (=, + =, ++, -,…), количество ветвей (вызовы других функций или методов класса) и количество условий (==, ›=,‹ =, if, else,…) внутри функции

Алгоритм дублирования кода также довольно точен. Он различает «похожий» код (та же структура, но разные значения) и «идентичный» код (та же структура и одинаковые значения).

Одна вещь, которая мне действительно нравится, - это раздел «Быстрые победы», который представляет собой раздел с пятью основными проблемами, которые снижают оценку качества вашего кода, поэтому вы, вероятно, найдете здесь потенциальный источник ошибок / неподдерживаемых код.

Но есть вещи, которые мне не нравятся. Самая важная из них заключается в том, что вы не можете настроить пороговые значения для того, чтобы считать Pull Request успешным или нет. По сути, если возникает новая проблема сложности, дублирование кода или уменьшение вашего тестового покрытия, независимо от того, в какой степени, он будет считать запрос на вытягивание неудавшимся. Эту функцию предоставляют другие инструменты, и было бы неплохо, если бы она была добавлена.

Другой недостаток заключается в том, что его алгоритм закрыт, и он остается неизменным, а это означает, что вы не можете добавлять дополнительные плагины или правила. Это хорошо, если алгоритм по умолчанию вам подходит, но если это не так, вы не можете его расширить.

Codacy

Он имеет лучший пользовательский интерфейс из всех проанализированных инструментов с очень чистым пользовательским интерфейсом. Это пример хорошего UX-интерфейса. Легко найти самую важную информацию и легко настроить основные параметры.

После нескольких дней использования вы чувствуете себя комфортно с инструментом и не зацикливаетесь на поиске необходимой информации. Вы заметили, что команда Codacy инвестировала в эту область.

Меры качества кода сгруппированы в 8 категорий: сложность кода, совместимость, подверженность ошибкам, безопасность, стиль кода, документация, производительность и неиспользуемый код. Поэтому сначала кажется, что он обеспечивает более подробный анализ, чем другие инструменты (тем не менее, это не совсем верно для Javascript).

Он также позволяет вам определять цели для ваших проектов либо для каждого файла (вы хотите уменьшить количество проблем или повысить оценку конкретного файла) или для каждой категории (т.е. повысить безопасность), и рекомендует шаги, которым нужно следовать, или проблемы, которые необходимо решить для достижения этих целей.

Что касается запросов на извлечение, вы можете настроить несколько пороговых значений, предоставив наиболее продвинутую конфигурацию, которую вы можете найти среди этих инструментов. Он имеет лучшую интеграцию с вашей VCS (например, Github, Bitbucket или Gitlab).

При этом, что не так с Codacy, если кажется, что в нем есть все, что нам нужно?

Что ж, в основном его статический анализ кода для Javascript не так хорош, как другие инструменты. В то время как другие инструменты вызвали у нас несколько проблем, связанных со сложностью наших проектов, Codacy не дала нам проблем почти во всех категориях качества кода для всех проектов.

Это связано с тем, что для проверки проблем с качеством кода в Javascript он использует ESLint, который мы уже включили в наш рабочий процесс, поэтому мы не ожидали, что от него возникнут проблемы. У него также есть другие механизмы правил, такие как PMD, но он кажется устаревшим (т.е. установленная версия PMD не может правильно читать ES6, поэтому у нас было много проблем с «ложным срабатыванием»).

Стоит упомянуть, что он включает Hadolint для анализа вашего Dockerfil e. 10 баллов здесь!

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

Таким образом, у Codacy есть все, что вы ожидаете от инструмента проверки кода…. но не для нас, поскольку он не обнаружил никаких проблем с качеством кода в нашем коде Javascript (наш код был идеальным xD). Однако я думаю, что Codacy может быть вашим правильным выбором, если анализ кода работает лучше для вашего языка программирования.

SonarQube

Каждый программист хотя бы раз в жизни слышал об этом инструменте. Я помню, как работал в Capgemini, когда кто-то из команды сказал: «Давайте проверим Sonar и исправим ошибки». Ох! прекрасные воспоминания :)

Это, безусловно, самый мощный инструмент качества кода с множеством мер и фильтров, но в котором используется более сложный интерфейс и конфигурация. В нем столько информации, что вы легко можете потеряться между цифрами и диаграммами.
Набор правил огромен, то есть для Javascript он включает 186 правил разных типов: запахи кода, ошибки, уязвимости и т. Д.

Основное различие между SonarQube и другими инструментами заключается в том, что анализ кода выполняется извне на вашем CI-сервере, а результат отправляется в SonarQube. Затем этот анализ обрабатывается SonarQube и сохраняется в базе данных для обслуживания. Это означает дополнительные усилия по настройке вашего CI-сервера.

Кроме того, вы можете настроить Профили качества, которые представляют собой набор правил, которые вы хотите применять при анализе, и Стробы качества, которые являются пороговыми значениями качества кода. Эта последняя функция отличается от Codacy тем, что SonarQube предупреждает вас о неудовлетворенных параметрах качества впоследствии, когда ваш код объединен, а не в самом запросе на слияние.

Тем не менее, проблемы с кодом, обнаруженные при анализе, могут быть добавлены в ваши запросы на слияние с помощью плагина. Этот плагин нужно настроить на своем CI-сервере, так что это еще одно дополнительное усилие по сравнению с другими инструментами.

Общее мнение о SonarQube таково, что он мощный, но требует больше усилий для настройки и интеграции в ваш рабочий процесс (хотя, если вы используете Travis в качестве сервера CI, есть надстройка, которая упрощает эту интеграцию).

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

И, наконец, один момент, который может сделать SonarQube вашим выбором, - это то, что вы можете скачать бесплатно (благодаря лицензии LGPL) и размещать себя либо использовать их облачный сервис под названием SonarCloud.

Наш выбор

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

Возможность предоставления информации об анализе кода в запросе на вытягивание - это то, чего мы действительно хотели, потому что мы верим в процесс непрерывного качества кода. Это заставило нас отказаться от Code Climate, поскольку у него нет такой интеграции с облаком BitBucket (нашей VCS).

Codacy не дала нам хорошего статического анализа кода для нашего кода Javascript. Мы уже используем ESLint, поэтому нам хотелось бы иметь другой механизм правил и алгоритмы для оценки качества нашего кода. Основная цель инструмента проверки кода - это на самом деле проверка, чего у нас не было с Codacy, поэтому мы были вынуждены отказаться и от этой опции.

Таким образом, мы наконец получили два варианта: Codebeat и SonarQube.

Ни у одного из них нет функции, которая нам нравится, которая помечает Pull Request как неуспешный, если определенные пороговые значения не достигнуты. Однако Codebeat сразу же дал нам очень хороший статический анализ кода, и мы обнаружили, что не было особой разницы с тем, что было предоставлено SonarQube.

Поскольку мы не хотели размещать SonarQube сами (актив для других компаний, но не для нас), учитывая время, необходимое для настройки SonarQube и интеграции в Codeship (наш сервер CI), наш руководитель отдела контроля качества Devgurus и я, наконец, решили двигаться вперед с Codebeat, хотя SonarQube тоже был бы хорошим выбором. Время покажет, хорошо мы выбрали или нет.

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

В Devgurus мы всегда инвестируем в технологии и предлагаем нашим клиентам самые инновационные технологии. Если вам интересно узнать больше историй успеха, не стесняйтесь обращаться к нам: [email protected]