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