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