Код-ревью
Мотивация
Поддержка и улучшение качества кодовой базы и, как следствие, продукта
Возможность формировать инженерные практики и адаптироваться к изменениям
Перед созданием MR
Разделяйте большие изменения на несколько MR
Разбиение изменений в рамках одного MR на несколько коммитов также упрощает ревью
Создавайте MR даже для изменений, не связанных с конкретной задачей в таск-трекере
Создание MR
Основная задача автора – предоставить внятное объяснение зачем вносятся изменения.
Хотя формат MR включает в себя ссылку на задачу, не стоит полагаться на то, что ревьювер перейдет по ней и будет самостоятельно выяснять контекст. Вся необходимая информация должна быть в описании MR.
Если в MR есть стилистические или другие неважные изменения, стоит указать на них и сказать ревьюверу важно ли обратить на них внимание.
Другим важным аспектом является подсвечивание рисков, связанных с выкаткой изменений, и шагов валидации решения.
Для вливания ветки в мастер достаточного одного аппрува:
Автор MR самостоятельно выбирает ревьювера для своего MR. Желательно, чтобы это был человек, знакомый с доменной областью. Т.к. в задаче в таск-трекере присутствует поле Reviewer, ревьювера крайне желательно указать его и там.
Любой член команды может провести дополнительное ревью изменений при наличии свободного времени, желания и согласовании с автором.
Ревью изменений
Для простых изменений (пара строк кода в рамках несложной логики, изменения текста в UI и пр.) проводить код-ревью не обязательно. Решение остается за автором MR.
Задачи автора MR
Поддерживать MR в актуальном состоянии: rebase, исправление конфликтов, правки в рамках ревью
Следить за тем, чтобы ревьювер не забыл про MR
Слияние с мастер-веткой
Задачи ревьювера
(глобальная) помочь команде поддерживать качество кодовой базы и продукта
(локальная) помочь автору изменений найти и учесть возможные недоработки
(личная) лучше понимать кодовую базу и продукт
Как делать ревью
MR без описания или с незаполненным шаблоном должен быть отклонен
Если какие-то вещи кажутся вам неочевидными или неясно почему они были сделаны – задавайте вопросы
Оставляя обратную связь, старайте категоризировать комментарии: вопрос, комментарий, ошибка, стиль кода и т.д. Например:
🐛 потенциальный баг или ошибка в коде
❓вопрос для прояснения непонятных моментов
🎨 комментарии по стилю кода
✏️ предложение к рефакторингу
Взвешенно предлагайте альтернативные варианты – конечное решение остается за автором MR
Привлекайте третью сторону, если не можете найти консенсус с автором
Закрывайте треды, которые вы инициировали – это поможет быстрее вмержить изменения
Не забывайте хвалить и подбадривать коллег. No blame culture here.
Как принимать ревью автору MR
Будьте дружелюбны и открыты к комментариям. Ваш ревьювер – ваш друг (см. Цели ревью и Задачи ревьювера).
Отвечая на комментарии ревьювера, старайтесь давать конкретные ответы и предложения
Помечайте обсуждение как resolved после принятия решения по нему – будут внесены правки, заведена новая задача
Привлекайте третью сторону, если не можете найти консенсус с ревьювером
Если по итогу ревью оказывается, что вы не учли моменты несущие риски для команды и продукта, MR ставится в статус "Заблокирован" и выносится на обсуждение.
Последнее обновление