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