ADPASS рекомендует материал к прочтению
IT Test
05.04.2024, 11:11

Code Review: полное руководство по внедрению

При невыстроенном процессе Code Review вливание новых реквестов замедляется, а разработчики могут конфликтовать. Объясняем, зачем внедрять эту практику, рассматриваем основные правила и рассказываем, как разработать регламент.

Польза Code Review очевидна: помогает посмотреть на код свежим взглядом, выявить ошибки и неточности, улучшить читаемость и качество, ознакомить других участников команды с определенным куском кода. Однако до сих пор от Code Review отказываются, используя фразы, вроде «у нас одинакового уровня разработчики» или «в команде всего один человек». Фронтенд-разработчик IT Test Марина Дударь с этими доводами не согласна и считает, что и кросс-командное Code Review, и селф-ревью помогают держать руку на пульсе.

С чего начинается Code Review

— Вы готовы дети? — Да, капитан!

Code convention — это внутренняя договоренность команды о правилах написания кода, стандарт его оформления. Обычно она включает в себя метод выбора имени и регистра, стандартизация спорных мест написания кода.

Чек-лист ревью — набор вопросов, ответы на которые помогут понять, можно ли вливать Merge Request (MR) . Он может быть более или менее наполненным в зависимости от компетенции создателя, но иметь базовый список на проекте станет хорошей точкой опоры.

Примеры действующих сейчас на проекте IT Test code convention и чек-лист ревью с уклоном в Angular.

Психология проверяющего и проверяемого

Нельзя просто так взять и написать коммент.

Предположим, у вас есть code style команды, чек-лист ревью и книга золотых практик работы с языком/фреймворком. Но и в таком случае можно столкнуться с внушительным списком правок.

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

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

Универсальный свод правил Code Review

  • Уважайте друг друга. MR — не место для сарказма.

  • Четко указывайте область исправления.

  • Объясняйте почему код нужно исправить — это поможет вырасти всем причастным.

  • Пишите, в какую сторону должен меняться участок кода — это ускорит процесс.

  • Помечайте префиксом NIT (сокращение от nitpick) неблокирующие реквест вопросы.

  • Хвалите автора MR за удачные решения.

Регламент процесса мерджа

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

  1. Создайте отдельный чат-ревью и как только открытый реквест будет готов к проверке, отправляйте ссылку.

  2. В это время открывший реквест разработчик смотрит другие реквесты и подготавливается к решению следующей задачи (лучше не приступать к новой до завершения текущей).

  3. После проведения ревью оповестите автора о том, что есть изменения.

Приведенные в статье советы применимы как на этапе внедрения практики Code Review, так и на моменте развития и масштабирования. Надеемся, они окажутся для вас полезными.


Больше экспертных материалов о разработке, дизайне и тестировании в Telegram-канале IT Test.

Вам понравится

Appbooster
25.04.2024
Russ
04.04.2024
Как создать полезный гид
для предпринимателей?