За свою карьеру я прошёл через все стадии отношения к код-ревью. Сначала я боялся открывать пул-реквесты и по полчаса перечитывал свой же диф, потом злился на придирки к запятым, а потом незаметно сам превратился в того самого ревьюера, который оставляет двадцать комментариев к одной строчке. Именно тогда я понял простую вещь: бесит не само ревью, а то, как мы его проводим. Ниже — набор правил, который превратил эту процедуру из повинности в спокойный и почти приятный ритуал.
Первое и самое недооценённое правило автора: маленькие PR. Когда я приношу коллеге на проверку восемьсот строк, я фактически прошу его пожертвовать час жизни и получить взамен чувство вины за поверхностное чтение. Поэтому я стараюсь держаться в диапазоне двухсот-четырёхсот строк и разбивать фичу на логические шаги: рефакторинг отдельно, миграция отдельно, бизнес-логика отдельно. Да, PR становится больше по количеству, но каждый из них читается за пятнадцать минут, и качество комментариев вырастает в разы. Если кусок всё-таки огромный, я честно об этом пишу в описании и подсказываю, с какого файла начинать чтение.
Второе правило — описание PR это не бюрократия, а интерфейс для ревьюера. Раньше я писал что-то вроде поправил баг, а теперь отвечаю на четыре вопроса: что изменилось, зачем это нужно, как это проверить руками и на что стоит смотреть особенно внимательно. Если решение спорное, я прямо пишу, какие были альтернативы и почему я их отбросил. Это экономит ревьюеру половину вопросов, а мне — половину раундов уточнений. Отдельно указываю номер задачи, чтобы контекст находился без поисков.
Теперь про сторону ревьюера, где я сам не ангел. Мой главный принцип сейчас звучит так: отделяй критичное от вкусовщины. Ошибка в логике, гонка, утечка ресурса, необработанный крайний случай — это то, что действительно блокирует мерж. А вот именование переменной или порядок методов — это тема для линтера и кодстайла, а не для дискуссии под каждым PR. Если замечание вкусовое, я помечаю его как необязательное и не настаиваю. Когда я перестал переписывать чужие решения под себя, конфликтов в команде стало заметно меньше.
Третье правило — про язык, и оно самое важное. Команда и приказ легко заменить на вопрос: вместо здесь неправильно спросить, а что будет, если сюда придёт пустой список. Вместо переделай — предложить, как бы я подошёл к этой задаче, и поинтересоваться, нет ли причин, которых я не вижу. Обычно причина есть, и разговор получается куда полезнее. И да, хвалить тоже нужно: фраза о том, что решение элегантное или что тесты написаны вовремя, стоит немного, а мотивации добавляет много. Люди охотнее правят код у того, кто замечает не только ошибки.
Четвёртый блок — это процессы и тайминги. У нас в команде мы договорились о времени реакции: если PR не срочный, ревьюер смотрит его в течение рабочего дня. Мы не отправляем большие изменения в пятницу вечером и не дёргаем человека в личных сообщениях через десять минут после открытия ветки. Договорились и о том, кто нажимает кнопку мержа: автор, после того как все комментарии закрыты. Такая мелочь убирает странное чувство, когда непонятно, можно уже вливать или нет.
Пятое — это то, что работает только на уровне команды. Мы завели шаблон для PR, подключили линтер и форматтер, чтобы спорить о стиле в комментариях было просто не о чем. Раз в пару недель обсуждаем на ретро, где ревью тормозит нас больше всего, и правим процесс. Новым людям даём смотреть на чужие ревью и просим ревьюить у них мягко, без ожидания мгновенного качества. Инструменты помогают, но культура всё равно важнее: если в команде принято объяснять, а не осуждать, любая автоматизация приживётся.
В итоге для меня код-ревью перестало быть дуэлью и стало обычной совместной работой над качеством. Автор приносит понятный контекст и небольшие изменения, ревьюер задаёт вопросы и не путает вкус с истиной, а договорённости о сроках и правилах снимают лишнее напряжение. На это ушло несколько лет проб и ошибок, но результат стоит того: код стал чище, а обсуждать его стало спокойнее. А как у вас в команде — какие правила ревью реально прижились, а что бесит и радует больше всего в комментариях коллег? Буду рад почитать ваш опыт в ответах.
Первое и самое недооценённое правило автора: маленькие PR. Когда я приношу коллеге на проверку восемьсот строк, я фактически прошу его пожертвовать час жизни и получить взамен чувство вины за поверхностное чтение. Поэтому я стараюсь держаться в диапазоне двухсот-четырёхсот строк и разбивать фичу на логические шаги: рефакторинг отдельно, миграция отдельно, бизнес-логика отдельно. Да, PR становится больше по количеству, но каждый из них читается за пятнадцать минут, и качество комментариев вырастает в разы. Если кусок всё-таки огромный, я честно об этом пишу в описании и подсказываю, с какого файла начинать чтение.
Второе правило — описание PR это не бюрократия, а интерфейс для ревьюера. Раньше я писал что-то вроде поправил баг, а теперь отвечаю на четыре вопроса: что изменилось, зачем это нужно, как это проверить руками и на что стоит смотреть особенно внимательно. Если решение спорное, я прямо пишу, какие были альтернативы и почему я их отбросил. Это экономит ревьюеру половину вопросов, а мне — половину раундов уточнений. Отдельно указываю номер задачи, чтобы контекст находился без поисков.
Теперь про сторону ревьюера, где я сам не ангел. Мой главный принцип сейчас звучит так: отделяй критичное от вкусовщины. Ошибка в логике, гонка, утечка ресурса, необработанный крайний случай — это то, что действительно блокирует мерж. А вот именование переменной или порядок методов — это тема для линтера и кодстайла, а не для дискуссии под каждым PR. Если замечание вкусовое, я помечаю его как необязательное и не настаиваю. Когда я перестал переписывать чужие решения под себя, конфликтов в команде стало заметно меньше.
Третье правило — про язык, и оно самое важное. Команда и приказ легко заменить на вопрос: вместо здесь неправильно спросить, а что будет, если сюда придёт пустой список. Вместо переделай — предложить, как бы я подошёл к этой задаче, и поинтересоваться, нет ли причин, которых я не вижу. Обычно причина есть, и разговор получается куда полезнее. И да, хвалить тоже нужно: фраза о том, что решение элегантное или что тесты написаны вовремя, стоит немного, а мотивации добавляет много. Люди охотнее правят код у того, кто замечает не только ошибки.
Четвёртый блок — это процессы и тайминги. У нас в команде мы договорились о времени реакции: если PR не срочный, ревьюер смотрит его в течение рабочего дня. Мы не отправляем большие изменения в пятницу вечером и не дёргаем человека в личных сообщениях через десять минут после открытия ветки. Договорились и о том, кто нажимает кнопку мержа: автор, после того как все комментарии закрыты. Такая мелочь убирает странное чувство, когда непонятно, можно уже вливать или нет.
Пятое — это то, что работает только на уровне команды. Мы завели шаблон для PR, подключили линтер и форматтер, чтобы спорить о стиле в комментариях было просто не о чем. Раз в пару недель обсуждаем на ретро, где ревью тормозит нас больше всего, и правим процесс. Новым людям даём смотреть на чужие ревью и просим ревьюить у них мягко, без ожидания мгновенного качества. Инструменты помогают, но культура всё равно важнее: если в команде принято объяснять, а не осуждать, любая автоматизация приживётся.
В итоге для меня код-ревью перестало быть дуэлью и стало обычной совместной работой над качеством. Автор приносит понятный контекст и небольшие изменения, ревьюер задаёт вопросы и не путает вкус с истиной, а договорённости о сроках и правилах снимают лишнее напряжение. На это ушло несколько лет проб и ошибок, но результат стоит того: код стал чище, а обсуждать его стало спокойнее. А как у вас в команде — какие правила ревью реально прижились, а что бесит и радует больше всего в комментариях коллег? Буду рад почитать ваш опыт в ответах.