Культура код-ревью, процесс ревью, обратная связь
Время освоения: ~40 минут Цель: Выстроить эффективный процесс код-ревью, который улучшает качество кода, ускоряет онбординг и создаёт культуру обучения без страха и блокеров
| Размер | Строк изменений | Время ревью | Рекомендация |
|---|---|---|---|
| S | < 50 строк | 5–15 минут | Идеальный размер, делайте так всегда |
| M | 50–200 строк | 15–30 минут | Хороший размер, приемлемо |
| L | 200–400 строк | 30–60 минут | На границе, лучше разбить |
| XL | > 400 строк | 60+ минут | Требует разбивки, ревьюеры устают |
| Приоритет | Категория | Что смотреть |
|---|---|---|
| Высокий | Корректность | Логика правильная? Граничные случаи обработаны? |
| Высокий | Безопасность | SQL injection, XSS, утечки данных? |
| Средний | Дизайн | Соответствует ли архитектуре? SOLID нарушен? |
| Средний | Тесты | Покрывают ли тесты новую логику? |
| Низкий | Читаемость | Понятны ли имена переменных и функций? |
| Низкий | Style/Nit | Форматирование, стиль (лучше автоматизировать) |
| Тип PR | Ожидаемое время первого ответа | Максимум |
|---|---|---|
| Hotfix / срочный | 1 час | 2 часа |
| Обычный PR | 1 рабочий день | 2 рабочих дня |
| Большой PR (L/XL) | 2 рабочих дня | 3 рабочих дня |
Код-ревью — один из самых мощных инструментов в арсенале инженерной команды. Но его часто воспринимают только как механизм поиска багов. В действительности код-ревью выполняет сразу несколько функций:
Функции код-ревью:
Ключевое отличие зрелого процесса от незрелого: в зрелой команде код-ревью — это диалог равных, где оба участника — и ревьюер, и автор — учатся.
💡 Ключевая мысль: Цель ревью — улучшить код, а не доказать, кто умнее. Комментарий «Это неправильно» закрывает разговор. Комментарий «Что думаешь о подходе X? Он решает проблему Y» — открывает.
Код-ревью может быть источником психологической боли — особенно для джунов и людей на новом месте. Один агрессивный комментарий может сделать человека молчаливым на месяцы.
Принципы безопасного ревью:
processOrder — глагол + существительное помогает сразу понять, что делает функция»Автор PR:
Ревьюер:
PR из 500+ строк — это антипаттерн. Вот почему:
Как делать маленькие PR:
Хорошее описание — это уважение к ревьюеру:
## Что изменено
Добавлен эндпоинт для создания заказов (POST /api/orders)
## Почему
Task #123: пользователи не могут создавать заказы через API
## Как тестировать
1. POST /api/orders с телом { product_id: 1, qty: 2 }
2. Ожидается: 201 Created с order_id в ответе
## Скриншоты / logs
[приложить если есть]
Linting, форматирование, type checking — это работа для CI, не для ревьюера. Если ревьюер пишет «здесь отсутствует пробел» — у вас нет автоматизации.
Автоматизировать через CI:
Nit (придирка): стилистическая мелочь, не влияет на функциональность.
Пример: nit: предпочитаю snake_case для локальных переменных, но это не блокер
Suggestion (предложение): есть лучший подход, но текущий тоже работает.
Пример: suggestion: можно использовать dict comprehension вместо цикла — будет читабельнее
Must-fix (обязательно исправить): баг, уязвимость, нарушение архитектурного решения.
Пример: must-fix: здесь возможен SQL injection — используй параметризованный запрос
| Плохо | Хорошо |
|---|---|
| «Это неправильно» | «Этот подход не обрабатывает случай пустого списка — упадёт с IndexError» |
| «Перепиши это» | «suggestion: этот блок можно упростить через filter(), станет читабельнее» |
| «Зачем ты так сделал?» | «Помоги понять — почему здесь синхронный вызов вместо async?» |
| «Очевидно же!» | «nit: имя d неочевидно — что насчёт order_data?» |
Без явных стандартов ревью превращается в спор о вкусах. Тимлид должен задокументировать:
«LGTM» (Looks Good To Me) без реального ревью — опасный паттерн. Признаки:
Как исправить: культура психологической безопасности, где вопросы поощряются. Тимлид должен сам задавать вопросы на ревью, показывая пример.
Если PR висит без ревью больше SLA — это блокер для команды и проблема cycle time. Тимлид должен:
Новый человек должен сначала ревьюить (а не только писать код). Это быстрый способ изучить кодовую базу, стандарты и архитектуру. Тимлид должен включать новичков в ревью с первой недели, объясняя «почему» а не только «что».
| Метрика | Что показывает | Цель |
|---|---|---|
| Time to First Review | Как быстро PR получает первый отзыв | < 4 часов |
| Review Turnaround Time | Полное время одного цикла ревью | < 1 дня |
| PR Cycle Time | От открытия PR до merge | < 2 дней |
| Review Coverage | % PR, у которых > 1 ревьюера | > 80% |
| Rework Rate | % PR с > 2 циклами ревью | < 20% |
| Ошибка | Почему это плохо | Как исправить |
|---|---|---|
| Ревьюировать стиль кода вручную | Трата времени на то, что делает автоматизация лучше | Настроить linter + formatter + CI, убрать style-комментарии из ревью |
| PR из 1000+ строк | Ревьюер устаёт, пропускает баги, cycle time растёт | Ввести правило: PR > 400 строк требует обоснования или разбивки |
| Нет SLA на ревью | PR висят днями, блокируют команду, растёт cycle time | Ввести и опубликовать SLA: 1 рабочий день для первого ответа |
| Комментарии без объяснения («исправь это») | Автор не понимает почему, обратная связь не развивает | Всегда объяснять причину и предлагать альтернативу |
| Все комментарии — must-fix | Автор воспринимает ревью как атаку, психологически небезопасно | Явно маркировать nit/suggestion/must-fix |
| LGTM без реального ревью | Баги проходят в продакшн, культура деградирует | Тимлид устанавливает пример глубокого ревью и задаёт вопросы сам |
Оцените текущий процесс код-ревью в команде:
Возьми 5 последних своих ревью-комментариев и перепиши их:
Код-ревью — это не контроль качества с контрольно-пропускным пунктом. Это практика коллективного владения кодом, где каждый участник учится и улучшает продукт. Тимлид задаёт тон этой культуры через собственный пример: как ревьюирует, как принимает обратную связь, как расставляет приоритеты.
Ключевые выводы:
🎯 Следующий шаг: Введи SLA на ревью в своей команде (1 рабочий день) и настрой автоматизацию для linting — это даст результат уже в первую неделю.
Время освоения: 40 минут Уровень: Продвинутый Для кого: Тимлиды, Engineering Managers, Senior Engineers
Вопросы ещё не добавлены
Вопросы для этой подтемы ещё не добавлены.