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