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