Что это такое
Перед тем как изменения попадут в общий код, их читает кто-то ещё и оставляет замечания. Автор правит, замечания повторяются или снимаются, изменения принимают.
По-русски это называют разбором кода, но термин «код-ревью» прижился и звучит нормально.
Зачем это нужно
Ошибки ловятся до того, как попали в работу. Чужой взгляд видит то, что вы перестали замечать.
Знания расходятся по команде. Все понемногу узнают, как устроены соседние части.
Новички растут быстрее всего. Для человека без опыта регулярный разбор его кода — самый мощный ускоритель, какой существует. Полгода с разбором дают больше, чем два года без него.
Именно поэтому на собеседовании стоит спрашивать, есть ли в компании разбор кода: место, где его нет, затормозит вас на год.
Как принимать замечания
Не спорьте с первой реакции. Первое чувство почти всегда «да я же правильно сделал». Дайте ему пройти, потом читайте по существу.
Отделяйте код от себя. Замечание к коду — не оценка вас как человека. Это трудно первые месяцы и легко потом.
Спрашивайте, если непонятно. «Не понял замечание, поясни» — нормальная реплика, а не признание слабости.
Не соглашаетесь — объясните. Спокойно, по делу: «Сделал так, потому что вот это. Если есть причина иначе, поменяю». Аргументированное возражение уважают.
Отвечайте на каждое замечание. Исправил или объяснил, почему нет. Молча проигнорированные комментарии раздражают сильнее всего.
Как давать замечания
Про код, а не про человека. Не «ты не подумал», а «здесь при пустом списке будет падение».
Объясняйте почему. Не «переделай», а «этот запрос выполнится в цикле сто раз, лучше вынести наружу».
Отделяйте важное от вкусовщины. Если это дело привычки, так и скажите: «необязательно, но я бы назвал иначе».
Хвалите за хорошее. Одна строчка «удачно вынес это в отдельную функцию» держит человека лучше, чем десять замечаний ломают.
Не переписывайте за автора. Ваша задача — показать проблему, а не сделать работу вместо него.
Что смотреть, если вы новичок
Кажется, что новичку нечего сказать о чужом коде. Это не так. Вы можете:
- Спросить, что непонятно. Если вам неясно, скорее всего, код и правда стоит пояснить.
- Проверить сценарии. Что будет при пустом вводе, при отсутствии данных, при повторном нажатии.
- Заметить расхождение с описанием задачи.
Вопрос от новичка часто ловит настоящую проблему просто потому, что он не знает, «как принято», и смотрит свежим взглядом.
Где потренироваться до работы
В чужих открытых проектах: отправьте правку и получите замечания. И в совместной работе над проектом — там вы будете и получать разбор, и давать его.
Это тот навык, который на первой работе заметен сразу: человек, привыкший к разбору кода, ведёт себя спокойно, а тот, для кого это впервые, обижается и тормозит команду.
Открытые роли по теме статьи
Читать полезно, а делать — ещё полезнее. В эти команды можно написать прямо сейчас:
- iOS-разработчик — MAIBO - MedTech-пилот для клиник
- Контент-маркетолог / комьюнити — CohortX — платформа командных пет-проектовмаркетингtelegramseoконтент
Похожие статьи
- Agreeing on technical decisionsWhy technology arguments drag on, how to tell an important decision from an unimportant one, and what to record so you don't argue twice.
- Как договариваться о технических решенияхПочему споры о технологиях затягиваются, как отличить важное решение от неважного и что записывать, чтобы не спорить дважды.
- Handing a project over to someone elseWhat to prepare, what to say out loud, what the code won't tell them, and how to know the handover actually happened.