Как делать код-ревью: руководство для команды 🔍

Код-ревью — это проверка изменений другого разработчика перед тем как они попадут в основную ветку. Один из самых ценных процессов в командной разработке.

Зачем нужно код-ревью

• 🐛 Ловит баги до продакшена, а не после
• 📚 Распространяет знания — ревьюер учится у автора и наоборот
• 💬 Фиксирует решения — обсуждение в PR остаётся навсегда
• 🎨 Поддерживает стиль — код выглядит одинаково вне зависимости от автора
• 🤝 Укрепляет команду — совместная ответственность за качество

Как ревьюить: роль ревьюера

Шаг 1: Прочитайте описание PR

Прежде чем смотреть код — прочитайте описание. Что изменилось? Зачем? Это контекст для понимания решений.

Шаг 2: Откройте вкладку Files Changed

Здесь построчный diff:
- 🟢 Зелёный (+) — добавленные строки
- 🔴 Красный (-) — удалённые строки
- ⚪ Белый — контекст без изменений

Шаг 3: Оставьте комментарии

Наведите мышку на номер строки — появится синяя кнопка +.

Три типа комментариев:

Обязательное изменение:

Здесь должна быть проверка на null, иначе упадём при пустом описании.
Предлагаю:
if description is None:
    description = ""

Предложение (не обязательно):

Suggestion: можно написать короче через walrus operator,
но это на твоё усмотрение — текущий вариант тоже ОК.

Вопрос/уточнение:

Почему здесь таймаут 30 секунд а не 10? Это намеренно?

Шаг 4: Выберите тип ревью

После добавления всех комментариев нажмите Review changes:

Что проверять при ревью

✅ Обязательно

• Логика: Правильно ли работает код? Все ли случаи обработаны?
• Безопасность: Нет ли SQL-инъекций, XSS, незащищённых данных?
• Тесты: Есть ли тесты на новую функциональность?
• Описание PR: Понятно ли что сделано и зачем?

👍 Хорошо проверить

• Производительность: Нет ли лишних запросов к базе, N+1 проблем?
• Читаемость: Понятны ли имена переменных и функций?
• Дублирование: Не изобретается ли велосипед который уже есть?

🔎 По возможности

• Документация: Обновлена ли документация если API изменился?
• Стиль: Соответствует ли код стандартам проекта?

Как писать хорошие комментарии

❌ Плохо

Это неправильно.

Перепиши.

Зачем ты так сделал???

✅ Хорошо

Здесь возможна ошибка: если список пустой, sorted() вернёт [],
но следующая строка ожидает хотя бы один элемент.
Предлагаю добавить проверку: if not items: return None

Это работает, но есть более идиоматичный способ через list comprehension:
result = [item.name for item in items if item.active]
Оставить как есть тоже OK — это предложение, не требование.

Правило: комментарий должен объяснять что не так и почему, а не просто говорить «плохо».

Тон ревью: nit, suggestion, blocker

В профессиональных командах принято маркировать серьёзность комментария:

nit: лучше назвать переменную `user_count` а не `cnt`
(мелочь, можно проигнорировать)

suggestion: можно вынести эту логику в отдельную функцию
(предложение, не обязательно)

blocker: здесь нет обработки ошибок сети, это упадёт в продакшене
(нужно исправить перед merge)

Как реагировать на ревью: роль автора

Правило 1: Ревью — про код, не про вас

Комментарий «эта функция слишком сложная» — не значит «ты плохой разработчик». Ревьюер помогает сделать продукт лучше.

Правило 2: Отвечайте на каждый комментарий

Исправил — добавил проверку на null, см. новый коммит.

Согласен, хороший момент. Изменил название переменной.

Хм, интересная идея. Оставлю пока так потому что это временный код,
но создам Issue чтобы не забыть.

Правило 3: Если не согласны — объясните почему

Я думал об этом, но выбрал текущий подход потому что [причина].
Можем обсудить если хочешь — открыт к диалогу.

Правило 4: После правок — сообщите ревьюеру

После нового push нажмите Re-request review рядом с именем ревьюера.
Это отправит уведомление: «автор обновил PR, посмотри снова».

Типичные ошибки при ревью

Ошибки ревьюера

❌ Nitpick bombing — 50 мелких комментариев про пробелы и форматирование
→ Настройте автоформаттер вместо ручных правок

❌ Молчаливый Approve — нажал Approve не читая
→ Если некогда ревьюить — честно скажите, пусть другой посмотрит

❌ Субъективные требования — «мне не нравится этот стиль»
→ Ревью должно быть про корректность, не вкусовщину

Ошибки автора

❌ Огромный PR — 2000 строк изменений
→ Разбивайте на маленькие PR, их легче ревьюить

❌ Нет описания — пустое поле Description
→ Всегда заполняйте шаблон описания PR

❌ Игнорирование комментариев — запушил и смёрджил сам
→ Уважайте процесс ревью даже если торопитесь

Ревью в GitHub Desktop

GitHub Desktop не показывает Code Review UI — это делается через браузер на github.com.

Рабочий процесс:
1. Получили ссылку на PR → открыли в браузере
2. Прочитали описание → вкладка Files Changed → оставили комментарии
3. Review changes → выбрали тип → Submit review
4. Автор увидит уведомление в GitHub

Хорошее ревью = хорошая команда

По исследованиям, команды с культурой ревью:
- Находят на 60% больше багов до продакшена
- Быстрее онбордят новых членов
- Имеют более низкий технический долг

Ревью — это инвестиция, а не трата времени.