Код-ревью — это процесс анализа кода, написанного разработчиком, перед его включением в основную ветку. В этой статье мы выделили несколько принципов, которые помогают команде Ryadom Tech проводить качественные и полезные код-ревью.
Командное участие в процессе
Все члены команды, независимо от уровня, должны участвовать в код-ревью. Часто только лиды и сеньоры проверяют код младших коллег, но это подход устаревший. Вовлеченность младших разработчиков в проверку кода старших приносит множество преимуществ.
Например, умение разбираться в чужом коде — важный навык, который стоит развивать с карьерного младенчества, чтобы в будущем было легче адаптироваться к новым обязанностям. Кроме того, анализ кода коллег позволяет открывать для себя новые методы и подходы к решению задач, что особенно важно для джуниоров, чьи задачи, как правило, проще.
И наконец, это безлимитная возможность учиться на чужих ошибках.
Правило двух "Ок"
Для включения кода в основную ветку требуется согласие как минимум двух членов команды. Это помогает получить независимые мнения и часто приводит к нахождению третьего — самого оптимального.
Если код писал лид, его должен одобрить хотя бы один коллега. Никто не застрахован от ошибок: любой человек может не выспаться, загрустить на созвонах или отвлечься на пустяки.
Если под запросом стоит нужное количество оков, он считается безопасным. Еще, естественно, код должен собраться и пройти все тесты, но об этом расскажем в следующей статье.
Критика
Разработчики иногда переживают из-за большого количества правок и комментариев к их коду. Важно помнить, что критикуется именно код, а не личность программиста. Например, если повар приготовил неудачный пирог, это не делает его плохим специалистом — значит, пирог мог бы быть лучше.
Всегда помните, что любая критика — ваша зона роста. Если вы не согласны с ревьювером, можно обсудить и прийти к истине. Все обсуждения должны вестись строго под реквестом, не уводите их в личные сообщения, чтобы ход ваших мыслей также видели и понимали коллеги.
Если договориться не удается, привлекается третий независимый участник.
Не решайте задачу дважды
Не стоит вчитываться в задачу коллеги, всматриваться в его решение, пытаться сопоставить бизнес-логику с постановкой. Не решайте задачу коллеги повторно. Лучше сосредоточьтесь на триггерах.
Триггеры — это сигналы, на которые обращает внимание опытный разработчик: плохой стиль кода, закомментированный код, todo в бизнес-логике, магические числа, медленные алгоритмы или неэффективное использование коллекций, апгрейд версий библиотеки без ознакомления с их чендж-логом и т. д.
Для каждой области разработки триггеры могут быть довольно специфичными. Например, в Android-разработке мы пристально смотрим на сущности Room. Если они изменились без написания миграции — сразу кричать в комментариях. Ведь это краш при запуске приложения. Такую сборку нельзя отдавать в тест.
С особым вниманием нужно отнестись к изменениям или доработкам коллеги в той области программы, которую писали вы. Если было удалено что-то важное, обязательно предупредите коллегу о возможных рисках.