Статьи

Как применить RuboCop к вашей большой кодовой базе Rails

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

Существуют различные инструменты, которые помогут вам достичь этой цели. В Codeship нам действительно нравится HoundCI, инструмент непрерывной интеграции для стиля кода. В этом посте я объясню, как мы используем HoundCI и RuboCop в Codeship и как мы представили их нашей команде.

Как работает HoundCI?

Во-первых, давайте рассмотрим, как работает HoundCI, чтобы все были на одной странице. HoundCI следит за вашими пиарами и проверяет код на соответствие вашему руководству по стилю. HoundCI будет комментировать только файлы, которые были изменены в PR. Это обеспечивает обратную связь для файлов, к которым вы фактически прикасаетесь, а не ко всей базе кода.

Если HoundCI обнаружит нарушения руководства по стилю, он прокомментирует PR, описывая, какое руководство вы нарушили. Вы по-прежнему можете решить, хотите ли вы исправить нарушения, но это, в первую очередь, лишит цели использовать HoundCI.

Под капотом HoundCI используются различные инструменты с открытым исходным кодом для написания кода. Например, он будет использовать RuboCop для проверки вашего кода Ruby и SCSS-Lint для SCSS и так далее. Вы можете получить обзор поддерживаемых языков в их  документации .

Использование конфигурации по умолчанию HoundCI

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

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

Попытка снова с RuboCop

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

Я начал играть с RuboCop (без HoundCI) и увидел, что наша кодовая база содержит около 900 предупреждений. Мы упустили нашу кодовую базу, поэтому количество предупреждений со временем росло.

В результате мы определили, что было несколько целей, которые мы хотели достичь:

  1. Сохранить статус-кво; не позволяйте этому ускользнуть.
  2. Улучшение кодовой базы с течением времени.
  3. Содействовать бойкотингу; исправить одну проблему с линтером за раз

Эти цели на самом деле сильно отличаются друг от друга и требуют разных решений.

Когда мы впервые попытались использовать HoundCI, мы следовали предложению HoundCI:

Могу ли я, чтобы гончая проверила весь свой репозиторий на предмет стиля?

Нет, и мы не рекомендуем это делать. Наше правило гласит: «не переписывайте существующий код в соответствии с руководством по стилю».

Звучит разумно. Почему я должен потратить недели на решение всех проблем? Мы можем сделать это со временем! Но, как я упоминал ранее, этот подход не подходит для нас.

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

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

# !/bin/bash

set -e

ALLOWED_WARNINGS=546 
warnings=`rubocop --format simple | grep "offenses detected" | cut -d " " -f4`

if [ $warnings -gt $ALLOWED_WARNINGS ] 
then 
  echo -e "allowed warnings $ALLOWED_WARNINGS" 
  echo -e "actual warnings $warnings" 
  echo -e "Too many rubocop warnings" 
  echo -e "Try running 'bin/check_rubocop_against_master'" 
  exit 1 
else 
  echo $warnings/$ALLOWED_WARNINGS is close enough ಠ_ಠ 
  exit 0 
fi

Отслеживание трещотки

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

Где мы сейчас?

Теперь мы можем постепенно обрабатывать предупреждения; нам не нужно исправлять их все сразу. Мы открываем PR, которые меньше и фиксируем несколько предупреждений здесь и там. При таком подходе мы уже сократили наши предупреждения пополам всего за две недели! Это действительно потрясающе.

Наша цель — получить 0 предупреждений и дать возможность HoundCI снова прокомментировать PR. Получив 0 предупреждений, HoundCI будет комментировать только те нарушения, которые мы недавно ввели. Это сильно уменьшит шум. Ни одному разработчику не нравится высокое отношение сигнал / шум.

Используете ли вы HoundCI или другие инструменты для рисования как часть процесса CI? Если да, с какими проблемами вы столкнулись, представляя их команде?

Эта статья первоначально появилась в блоге Codeship Бенджамина Фрича.