Как пройти первое код-ревью

Дали первую задачу, ты её сделал — и теперь надо отправлять на ревью. Отправляешь, и в голове всплывает: сейчас откроют, посмотрят и поймут, что тебя зря взяли. Сидишь как на иголках. На самом деле ревьюер откроет твой пр, напишет тучу комментариев, ты их за пару итераций поправишь, и задачу апрувнут. Первый раз страшно всем. Хуже, когда страшно и на десятом PR: ревью так и осталось экзаменом вместо рабочей процедуры. Что делать:

До отправки
Самое дешёвое, что можно сделать для лёгкого ревью, — не сваливать в один PR несколько дней работы. Двести строк ревьюер читает. Две тысячи — просматривает по диагонали, а чаще жмет «апрув» или отдает нейронке. Поэтому либо баг уедет в прод, либо будешь по указке нейронки бесконечно переписывать свой огромный пр.

Отсюда навык, который стоит качать с первого дня, — декомпозиция. Разбивай задачу так, чтобы каждый кусок был законченной мыслью: тут миграция, тут ручка, тут кнопка в интерфейсе. Отрефакторил по дороге — отдельным PR, переименовал пачку файлов — отдельным. Проверять такое легко, а делать — ещё легче.

Дальше описание: что сделал, зачем, куда смотреть в первую очередь, что оставил на потом. Если решение неочевидное, напиши, почему выбрал его, а не соседнее, иначе вопрос всё равно прилетит, просто через сутки. Пустое описание читается как «разбирайся сам». И перед тем как ставить на ревьюе, пройдись по диффу как по чужому: забытые логи, закомментированный код, закоммиченный локальный конфиг, куски, понятные только тебе. Проще всего открыть draft PR заранее и вернуться через пару часов — половину косяков увидишь сам.

Когда пришли комментарии
Сначала про количество. Пятнадцать комментариев на первом PR — норма: ты просто ещё не знаешь договорённостей команды, а они нигде не записаны. Через месяц их будет вдвое меньше. Считать их своей оценкой — быстрый способ возненавидеть ревью. И отвечай на все «ок, поправил»: ревьюер должен видеть, что комментарий не потерялся. Молчаливо закрытые ветки и PR, который висит третий день, раздражают сильнее, чем плохой код.

Замечания при этом не равны между собой. «Падает на пустом массиве» — чинить обязательно. А «назвал бы переменную иначе» остаётся на твоё усмотрение, но ответить всё равно нужно: «поправил» или «оставлю так, потому что…». И написаны замечания почти всегда про код, а не про тебя: «тут можно проще», «тут будет больно поддерживать». Формулировки бывают сухими, особенно если ревьюер спешит, — это не наезд. А если кто-то правда переходит на личности, это уже не про ревью, с этим нужно идти к ментору или лиду.

Первый инстинкт на замечание — оправдаться, и он так себе: объяснение закрывает разговор, который ещё нужен. Не понял, чем предложенный вариант лучше, — спроси. Либо тебе объяснят, либо окажется, что ревьюер не видел контекста, и вопрос снимется сам. А если не согласен — скажи, спокойно и по делу, ровно для этого ревью и существует. Но одного круга аргументов достаточно: если и после него не расходитесь, то идите в личку или созвон. Ветка на двадцать сообщений никого не убеждает и тормозит задачу.

Вдолгую
Заведи тупой md-файл и складывай туда каждое замечание. Эффект появится месяца через два: часть комментариев перестанет приходить, потому что ты уже пишешь так сразу. А файл превратится в свод того, как в команде принято писать код: нигде не задокументировано, но прилетает стабильно. И читай чужие PR, особенно сеньорские: под ними обычно то же самое — спор про архитектуру, вопросы про обработку ошибок. Идеального кода не пишет никто. А когда ревьюишь сам, видно другую сторону: ты не ищешь, до чего докопаться, ты просто пытаешься понять код.

Короче
Ревью — просто рабочий момент, приговоров там не выносят. Маленькие PR, описание, self-review, ответ на каждый комментарий, вопрос вместо оправдания — и через пару месяцев обнаруживаешь, что щёлкаешь задачи как орешки, а твои PR спокойно проходят ревью. Помни идеального кода не пишет никто. Если хочешь ускорить свой рост и подтянуть базу обрати внимание на наших курсы ПРО, где мы как раз обсуждаем такие моменты.
➡️ Записаться

Подписаться: @chad_protocol