skip to main content

Код-ревью — как, зачем, почему

js

Кратко 🔗

В индустрии разработки программ очень распространена практика код-ревью. Программист отправляет написанный код своим коллегам. Они просматривают код и высказывают свои замечания.

Такой подход позволяет найти потенциальные проблемы, которые не заметил автор. Кроме того, такая практика распространяет знания внутри команды и помогает всем инженерам хорошо разбираться в коде.

Как происходит 🔗

Обычно разработчик отправляет на ревью набор изменений, которые решают определенную задачу — добавляют новую функциональность или исправляют ошибку. Чаще всего, такие изменения программист делает в своей ветке, а перед слиянием в основную запрашивает обзор своих изменений у коллег.

Отправка изменений на код-ревью происходит через пул-реквесты. Для прохождения код-ревью нужно получить одобрение одного или нескольких коллег. Способ выбора коллег для проведения ревью зависит от процессов внутри компании.

Пул-реквест (PR) — это предложение слить изменения в ветке разработчика с другой веткой. Иногда их называют мердж-реквестами (MR).

Типичной код-ревью к пул-реквесту на GitHub выглядит так:

Пример обсуждения в пул-реквесте

В некоторых командах код-ревью — это опциональный процесс, автор изменений сам решает, нужен ли ему сторонний взгляд. Такой подход помогает разгрузить разработчиков, не заставляя их просматривать большое количество простых правок. С другой стороны, при таком подходе на автора ложиться большая ответственность за качество написанного кода.

В работе 🔗

Код-ревью — это место, где особенно ярко проявляются софт-скилы инженеров. Провести хорошее код-ревью сложнее, чем написать хороший код.

Не расстраиваться 🔗

Не стоит воспринимать комментарии к коду как личное оскорбление.

Коллеги не ставят перед собой цели обидеть автора кода. Задача код-ревью — оценить реализованное решение, найти ошибки или потенциальные проблемы. Если ревьювер нашёл какую-то проблему — это хорошо, ведь так она будет решена сразу и не повлияет на пользователей.

Ругать код, а не автора 🔗

Многие люди совершенно не специально могут обидеть автора изменений, недостаточно мягко формулируя мысли:

❌ «Ты болван, тут нужно использовать пул коннектов!»

✅ «Слушай, а почему тут не используется пул коннектов? Мне кажется, это может привести к проблемам с производительностью»

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

Смотреть вглубь 🔗

При обзоре чужого решения велик соблазн давать мелкие советы. Это называется эффектом велосипедного сарая. Он создается, потому что для обсуждения сложных, глубоких вопросов нужно сильно погружаться в контекст внесённых изменений, а это сложно. Намного проще написать десяток комментариев о забытых точках с запятой и спокойно продолжить заниматься своей задачей.

Очень важно при код-ревью сосредоточиваться на том, что именно делает этот код, смотреть на его расширяемость, читаемость и удобство сопровождения. А расставленные пробелы, точки с запятой и другие мелочи лучше оставить статическому анализатору.