Code Review: полное руководство по внедрению
При невыстроенном процессе Code Review вливание новых реквестов замедляется, а разработчики могут конфликтовать. Объясняем, зачем внедрять эту практику, рассматриваем основные правила и рассказываем, как разработать регламент.
Польза Code Review очевидна: помогает посмотреть на код свежим взглядом, выявить ошибки и неточности, улучшить читаемость и качество, ознакомить других участников команды с определенным куском кода. Однако до сих пор от Code Review отказываются, используя фразы, вроде «у нас одинакового уровня разработчики» или «в команде всего один человек». Фронтенд-разработчик IT Test Марина Дударь с этими доводами не согласна и считает, что и кросс-командное Code Review, и селф-ревью помогают держать руку на пульсе.
С чего начинается Code Review
- Вы готовы дети?
- Да, капитан!
В первую очередь, нужно принять, что ревью – это не прихоть, а полезная необходимость. У команды должна быть база из code convention и чек-листа, которая в идеале создана совместными усилиями, а также правило о том, что ревью реквеста с пометкой ASAP нельзя откладывать на неопределенный срок.
*Code convention – это внутренняя договоренность команды о правилах написания кода, стандарт его оформления. Обычно она включает в себя метод выбора имени и регистра, стандартизация спорных мест написания кода.
**Чек-лист ревью – набор вопросов, ответы на которые помогут понять, можно ли вливать Merge Request (MR) . Он может быть более или менее наполненным в зависимости от компетенции создателя, но иметь базовый список на проекте станет хорошей точкой опоры.
Примеры действующих сейчас на проекте IT Test code convention и чек-лист ревью с уклоном в Angular.
Психология проверяющего и проверяемого
Нельзя просто так взять и написать коммент
Предположим, у вас есть code style команды, чек-лист ревью и книга золотых практик работы с языком/фреймворком. Но и в таком случае можно столкнуться с внушительным списком правок.
Code Review может состоять из нескольких итераций. Для начала стоит остановиться на глобальных проблемах: правильно ли спроектирован код, в том ли месте он расположен, решает ли он задачу, соответствует ли принятым правилам стиля и нейминга. На второй итерации переходим к более детальному осмотру реквеста.
Не забывайте: чем больше итераций, тем меньше сил и концентрации внимания у всех сторон. Нет предела совершенству, но нужно вовремя остановиться.
В идеальном мире автор реквеста принимает указания исключительно как зону роста и развития, но даже зрелые мидлы не застрахованы от обиды. Поэтому умение подобрать слова для описания комментариев – особый софт скил.
Универсальный свод правил Code Review
Уважайте друг друга. MR – не место для сарказма.
Четко указывайте область исправления.
- Объясняйте почему код нужно исправить – это поможет вырасти всем причастным.
Пишите, в какую сторону должен меняться участок кода – это ускорит процесс.
Помечайте префиксом NIT (сокращение от nitpick) неблокирующие реквест вопросы.
Хвалите автора MR за удачные решения
Если ревьюер спрашивает, «что автор хотел сказать этой строчкой», то стоит переписать код так, чтобы вопрос отпал.
Регламент процесса мерджа
Вопрос временных рамок Code Review, пожалуй, самый болезненный. Для того, чтобы поставить жесткие рамки для процесса мерджа на проекте, придерживайтесь следующих шагов.
- Создайте отдельный чат-ревью и как только открытый реквест будет готов к проверке, отправляйте ссылку.
- В это время открывший реквест разработчик смотрит другие реквесты и подготавливается к решению следующей задачи (лучше не приступать к новой до завершения текущей).
- После проведения ревью оповестите автора о том, что есть изменения.
Приведенные в статье советы применимы как на этапе внедрения практики Code Review, так и на моменте развития и масштабирования. Надеемся, они окажутся для вас полезными.
Больше экспертных материалов о разработке, дизайне и тестировании в Telegram-канале IT Test.