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