Sonar: автоматизируем проверку качества кода

“Иногда, читая чужой код, мне становится страшно, когда я пытаюсь представить процессы, проходящие в голове автора...”

Вам доводилось проводить code review своих проектов? А чужих? Процесс этот довольно трудоемкий, если производить его вручную, а к тому же, пока вы будете просматривать одну часть проекта, кто-нибудь обязательно успеет нагадить в другой. Не то, чтобы ручной труд занятие неблагодарное, но зачем, если его можно автоматизировать? Что автоматизировать и каким образом - об этом сегодня и поговорим.

Обычно выделяют следующие базовые показатели качественного кода:

- процент покрытия unit-тестами (весь покрытый тестами, абсолютно весь...)

- связность компонентов: цикличность (пересвязывали)

- отсутствие связности внутри методов: LCOM4 (недосвязывали)

- процент дублирования кода (есть такая религия - копипейст)

- сложность ветвления (if-ом кода не испортишь?)

- покрытие комментариями публичного API (чукча не читатель - чукча писатель)

- соответствие стилистическим нормам (как там учили в школе - красная строка размеров в два пальца?)

- прочие правила хорошего тона (это стул - на нем сидят, это стол - за ним едят)

Как видите, показателей много. Систем анализа, кстати сказать, не меньше. По факту, на каждый показатель найдется как минимум одна узко заточенная утилита. Покрытие можно анализировать при помощи EclEmma или Cobertura, анализ кода на дубликаты и соответствие правилам хорошего тона отлично выполняет PMD (подробный список утилит статического анализа кода можно посмотреть на wikipedia). Но мало просто проанализировать код - важно еще отследить историю изменений, и желательно делать это без лишних телодвижений и трехэтажных скриптов. Поэтому, без лишних слов - Sonar. Поприветствуем стоя!

Хороший слоган, не правда ли? Если к термину “contineous integration” мы все давно привыкли, то Sonar вводит новое в искусство управления жизненным циклом проектов: “Continuous Code Quality Management”. Прежде чем мы перейдем к более детальному рассмотрению возможностей Sonar, давайте ответим на вопрос: “Не является ли процесс непрерывного контроля качества кода всего лишь погоней за красивыми циферками?”. Вы когда-нибудь пробовали экономить на unit-тестировании? Обычно, в такой ситуации ваша производительность при работе над проектом будет выглядеть так:

То же самое происходит и при несоблюдении всех остальных норма качества кода. За одним маленьким исключением: возможно, если большую часть проекта пишет один человек, он и не ощутит просадки своей производительности, а вот все остальные разработчики будут злостно ругаться пытаясь понять его код. Не думаю, что стоит строить разработку на такого рода Чаках Норрисах, если с ними что-то случится, то вы по полной ощутите все “прелести” кода с неповторимым “авторским стилем”.

Что же такое Sonar? С технической точки зрения это набор утилит для тестирования качества кода, собранных вокруг одного инстанса Jetty. Sonar не только производит анализ кода, но и сохраняет историю в базу данных (по умолчанию используется встроенная Derby). Собранные данные можно просматривать при помощи виджетов через веб-интерфейс. Выглядит это так:

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

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

Найдя проблему, вы можете либо поправить ее, либо, откомментировать и назначить на конкретного человека. Можно сказать, что “Rules violations” похожи на тикеты в RedMine, с одной лишь разницей - их закрытием занимается сам Sonar.

Любой файл исходного кода можно просмотреть через web-интерфейс, переключаясь по вкладкам “Coverage”, “Dependencies”, “Duplications”, “LCOM4”, “PMD”, “Source”, “Violations”. Если что-то в коде вам не понравилось, но Sonar не пометил этот блок кода, вы можете сами добавить “violation”.

История изменения качества кода проекта доступна в стандартном дэшборде “Time Machine”:

Впечатлят? Лично меня - очень. И не стоит забывать, что платформа распространяется под лицензией LGPL. Честно сказать, меня поразило, что продукт такого уровня и качества исполнения распространяется свободно.

Описав все прелести Sonar, я чуть не забыл об очень важной вещи - развертывание. Какие технико-людские затраты потребует внедрение платформы непрерывного анализа качества кода в софтверной компании? 5 минут. Из них большая часть времени уйдет на открытия браузера и скачивание дистрибутива. Если в вашей компании используется Maven, то после распаковки и запуска дистрибутива sonar, необходимо добавить в файл m2/settings.xml профиль с адресом сервера. Далее создайте в сценарии сборки maven-проекта цель sonar:sonar, выполнив которую, можете открыть web-интерфейс и насладиться изучением метрик! Изучив возможности и метрики доступные “из коробки”, можете посмотреть список плагинов для Sonar.

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

P.S.: «Идет мужик по лесу и видит, как кто-то пилит дерево, упирается изо всех сил. Но видно, что у него плохо получается. Мужик подошел, внимательно присмотрелся, и говорит — «слушай, ты бы наточил пилу, у тебя дело быстрее пойдет…» На что ему сразу же грубо ответили: «Некогда мне пилу точить, пилить надо…»