Lucky_Roman
New member
Начну с того, что мне и самому бывало тошно читать комменты от ревьюеров — мелкий стиль, споры о именование, и главное, ощущение, что код смотрит не коллега, а инспектор ГАИ. В команде из восьми разработчиков у нас средний цикл ревью тянулся два-три дня, и каждый раз это превращалось в пинг-понг: я правлю, автор спорит, я пишу длинное объяснение, и так по кругу. В какой-то момент я понял, что проблема не в людях, а в процессе — и начал экспериментировать.
Первое, что я сделал — ввёл чёткие правила для комментариев. Любой комментарий обязан содержать одно из трёх слов: «блок», «предложение» или «вопрос». «Блок» — это то, что не даст PR merged, «предложение» — то, что можно обсудить, «вопрос» — просто любопытство автора. С этого момента количество бесмысленных споров упало на 70 процентов. Люди перестали тратить время на разбор, что именно имелось в виду под «может быть стоит подумать о…».
Второе — я начал ревьювать кодом, а не текстом. Вместо абстрактных комментариев типа «здесь лучше сделать через композицию» я кидал готовый diff или короткий пример прямо в комментарии. Да, это требует чуть больше усилий от ревьюера, но экономит часы на переписке. Автор не гадает, не пишет новое решение, не спорит — он просто применяет подсказку.
Третье — таймбокс. Мы договорились, что ревьюер обязан посмотреть PR в течение четырёх рабочих часов. Если не успел — передаёт коллеге. Звучит жёстко, но на практике это сработало как волшебная таблетка: люди перестали откладывать ревью «на потом», потому что знали, что им придётся возвращаться. Средний цикл сократился с двух дней до четырёх часов.
Четвёртое — обязательный размер PR. Мы ввели жёсткое правило: больше 400 строк изменений в одном PR — автоматически отправляю обратно. Никто не хочет читать роман в пятницу вечером. Маленькие PR ревьюятся быстро, легко, с удовольствием. Да, это требует от разработчиков чуть больше дисциплины при коммитах, но эффект колоссальный.
И последнее — я перестал ревьюить код в момент написания и начал делать это через час-два. Да, это противоречит интуиции «чем раньше, тем лучше». Но на практике я заметил, что автор кода к тому моменту уже сам нашёл половину проблем и убрал их, а я смотрел на уже отредактированную версию — без суеты и стресса. Плюс, я сам стал писать ревью спокойнее, без давления «ну что, уже 200 строк, успел?». Среднее время на один PR сократилось с 35 минут до 15.
В итоге цикл ревью у нас стал вдвое короче, количество конфликтов между авторами и ревьюерами практически исчезло, а код стал стабильнее — потому что ревью перестало быть формальностью и стало живым диалогом. Если вам знакома ситуация, когда ревью превращается в войну или бесконечную переписку — попробуйте хотя бы одно из этих правил. С чего начнёте?
Первое, что я сделал — ввёл чёткие правила для комментариев. Любой комментарий обязан содержать одно из трёх слов: «блок», «предложение» или «вопрос». «Блок» — это то, что не даст PR merged, «предложение» — то, что можно обсудить, «вопрос» — просто любопытство автора. С этого момента количество бесмысленных споров упало на 70 процентов. Люди перестали тратить время на разбор, что именно имелось в виду под «может быть стоит подумать о…».
Второе — я начал ревьювать кодом, а не текстом. Вместо абстрактных комментариев типа «здесь лучше сделать через композицию» я кидал готовый diff или короткий пример прямо в комментарии. Да, это требует чуть больше усилий от ревьюера, но экономит часы на переписке. Автор не гадает, не пишет новое решение, не спорит — он просто применяет подсказку.
Третье — таймбокс. Мы договорились, что ревьюер обязан посмотреть PR в течение четырёх рабочих часов. Если не успел — передаёт коллеге. Звучит жёстко, но на практике это сработало как волшебная таблетка: люди перестали откладывать ревью «на потом», потому что знали, что им придётся возвращаться. Средний цикл сократился с двух дней до четырёх часов.
Четвёртое — обязательный размер PR. Мы ввели жёсткое правило: больше 400 строк изменений в одном PR — автоматически отправляю обратно. Никто не хочет читать роман в пятницу вечером. Маленькие PR ревьюятся быстро, легко, с удовольствием. Да, это требует от разработчиков чуть больше дисциплины при коммитах, но эффект колоссальный.
И последнее — я перестал ревьюить код в момент написания и начал делать это через час-два. Да, это противоречит интуиции «чем раньше, тем лучше». Но на практике я заметил, что автор кода к тому моменту уже сам нашёл половину проблем и убрал их, а я смотрел на уже отредактированную версию — без суеты и стресса. Плюс, я сам стал писать ревью спокойнее, без давления «ну что, уже 200 строк, успел?». Среднее время на один PR сократилось с 35 минут до 15.
В итоге цикл ревью у нас стал вдвое короче, количество конфликтов между авторами и ревьюерами практически исчезло, а код стал стабильнее — потому что ревью перестало быть формальностью и стало живым диалогом. Если вам знакома ситуация, когда ревью превращается в войну или бесконечную переписку — попробуйте хотя бы одно из этих правил. С чего начнёте?