Sergey.Mikhailov
New member
Я лет десять работаю в IT и за это время пережил, наверное, тысячи код-ревью. Были такие, после которых хотелось закрыть ноутбук и уйти в лес. А были такие, где за пятнадцать минут ловились серьёзные баги, рождались хорошие идеи и никто не чувствовал себя униженным. Разница не в технологиях, а в правилах, которые команда принимает заранее. Ниже — восемь правил, которые у нас реально снизили уровень раздражения.
Правило первое: ревьюим код, а не человека. Фраза «ты опять написал ерунду» убивает мотивацию быстрее, чем любой баг в проде. Я стараюсь писать «здесь может быть гонка, давай обсудим» вместо «ты не понимаешь, как работают потоки». Правило второе: маленькие пул-реквесты. Если в диффе 800 строк, ревьюер либо устанет, либо пропустит важное. Мы договорились держать изменения в пределах одной задачи и стараться не смешивать рефакторинг с новой функциональностью.
Правило третье: сначала контекст, потом придирки. Автор пишет, что и зачем меняется, какие есть ограничения и где он сомневается. Ревьюеру не нужно угадывать. Правило четвёртое: разделяйте блокеры и предложения. У нас есть три метки: блокер, вопрос и придирка. Блокер останавливает мерж, вопрос требует ответа, придирка — просто мнение. Это спасает от споров о пробелах и вкусовщине.
Правило пятое: не подвешивайте ревью. Если я открыл пул-реквест утром, а комментарии пришли через три дня, я уже переключился на другую задачу. Мы стараемся давать первый отклик в течение рабочего дня, пусть даже короткий. Правило шестое: один-два ревьюера, не больше. Когда комментарии пишут пять человек, автор тонет в противоречивых советах. Лучше назначить ответственного, а остальные подключаются только по необходимости.
Правило седьмое: автоматизируйте всё, что можно. Форматирование, линтеры, тесты, проверка типов — это не работа для человека. Люди должны смотреть на логику, архитектуру, читаемость и граничные случаи. Правило восьмое: закрывайте цикл по-человечески. После мержа напишите спасибо, отметьте удачные решения, а не только ошибки. Я заметил, что команды, где хвалят за хороший код, ревьюят быстрее и спокойнее.
У нас эти правила не появились за один день. Сначала мы ввели ротацию ревьюеров, потом чек-лист из пяти пунктов, потом договорились о тоне. Через пару месяцев средний размер пул-реквеста упал примерно с восьмисот строк до ста пятидесяти, а количество конфликтов в комментариях сократилось заметно. Код-ревью всё ещё требует времени, но перестал быть местом для выяснения отношений.
Конечно, восемь правил — не волшебная таблетка. В маленькой команде можно договориться быстрее, в большой нужна дисциплина. Но если хотя бы начать с уважения, маленьких изменений и чётких меток, воздух в команде становится чище. А какие правила код-ревью помогают именно вам не сходить с ума и при этом держать качество? Поделитесь своим опытом, буду рад почитать.
Правило первое: ревьюим код, а не человека. Фраза «ты опять написал ерунду» убивает мотивацию быстрее, чем любой баг в проде. Я стараюсь писать «здесь может быть гонка, давай обсудим» вместо «ты не понимаешь, как работают потоки». Правило второе: маленькие пул-реквесты. Если в диффе 800 строк, ревьюер либо устанет, либо пропустит важное. Мы договорились держать изменения в пределах одной задачи и стараться не смешивать рефакторинг с новой функциональностью.
Правило третье: сначала контекст, потом придирки. Автор пишет, что и зачем меняется, какие есть ограничения и где он сомневается. Ревьюеру не нужно угадывать. Правило четвёртое: разделяйте блокеры и предложения. У нас есть три метки: блокер, вопрос и придирка. Блокер останавливает мерж, вопрос требует ответа, придирка — просто мнение. Это спасает от споров о пробелах и вкусовщине.
Правило пятое: не подвешивайте ревью. Если я открыл пул-реквест утром, а комментарии пришли через три дня, я уже переключился на другую задачу. Мы стараемся давать первый отклик в течение рабочего дня, пусть даже короткий. Правило шестое: один-два ревьюера, не больше. Когда комментарии пишут пять человек, автор тонет в противоречивых советах. Лучше назначить ответственного, а остальные подключаются только по необходимости.
Правило седьмое: автоматизируйте всё, что можно. Форматирование, линтеры, тесты, проверка типов — это не работа для человека. Люди должны смотреть на логику, архитектуру, читаемость и граничные случаи. Правило восьмое: закрывайте цикл по-человечески. После мержа напишите спасибо, отметьте удачные решения, а не только ошибки. Я заметил, что команды, где хвалят за хороший код, ревьюят быстрее и спокойнее.
У нас эти правила не появились за один день. Сначала мы ввели ротацию ревьюеров, потом чек-лист из пяти пунктов, потом договорились о тоне. Через пару месяцев средний размер пул-реквеста упал примерно с восьмисот строк до ста пятидесяти, а количество конфликтов в комментариях сократилось заметно. Код-ревью всё ещё требует времени, но перестал быть местом для выяснения отношений.
Конечно, восемь правил — не волшебная таблетка. В маленькой команде можно договориться быстрее, в большой нужна дисциплина. Но если хотя бы начать с уважения, маленьких изменений и чётких меток, воздух в команде становится чище. А какие правила код-ревью помогают именно вам не сходить с ума и при этом держать качество? Поделитесь своим опытом, буду рад почитать.