Code Review: лучшие практики

Зачем нужен Code Review

Code Review (ревью кода) — проверка изменений другим разработчиком перед тем, как код попадёт в основную ветку. Это не формальность, а рабочий инструмент: ревью ловит баги, поддерживает стиль, распространяет знания и помогает всей команде расти.

Google в исследовании обнаружил, что Code Review находить баги на 15-20% чаще, чем одного тестирования. А ещё это лучший способ познакомить нового разработчика с кодовой базой — через его PR и через ревью чужих.

Как автору подготовить PR

Один PR — одна задача

❌ Плохо: PR «Добавил поиск, починил баг с логином, обновил README»
✅ Хорошо: PR «feat: добавил поиск задач с debounce и фильтрацией»

Маленькие PR ревьют лучше. Идеальный размер — до 400 строк. Больше 800 — почти никто не читает внимательно. Если задача большая, разбейте на несколько PR:

PR #1: feat: add search API service
PR #2: feat: add search input component with debounce
PR #3: feat: integrate search into task list page

Понятное описание

## Что сделано
Добавлен поиск задач с автодополнением и debounce 300ms.

## Как проверить
1. Открыть /tasks
2. Начать вводить в поле поиска
3. Убедиться, что результаты фильтруются

## Скриншот
[скриншот UI]

## Связанная задача
Closes #42

Перед отправкой на ревью

# Убедиться, что CI проходит
npm run lint
npm run test
npm run build

# Проверить, что нет случайных изменений
git diff main...HEAD --stat

# Найти забытыые console.log и debugger
git diff main...HEAD | grep -E "console\.|debugger"

Само-ревью

Перед добавлением ревьюеров просмотрите свой PR самостоятельно. Пройдитесь по диффу — часто находятся опечатки, забытые импорты или лишние изменения. Это экономит время ревьюера.

Как ревьюить

Порядок чтения

1. Описание PR — понять контекст и цель
2. Файлы по степени важности — сначала бизнес-логика, потом тесты, в конце стили
3. Тесты — покрывают ли они логику, есть ли edge cases

Категории замечаний

Используйте префиксы, чтобы автор понимал серьёзность:

Что НЕ должен проверять ревьюер

Что ДОЛЖЕН проверять ревьюер:

• Правильность логики
• Архитектурные решения
• Обработка ошибок и edge cases
• Читаемость и поддерживаемость
• Достаточность тестов

Чеклист ревьюера

Корректность

• Код делает то, что описано в PR
• Обрабатываются ошибки (try/catch, catchError, error states)
• Нет edge cases: пустой массив, null, undefined, пустая строка
• Условия корректны (=== вместо ==, правильные операторы)
• Циклы не зависят при пустых данных

Безопасность

• Нет innerHTML без санитизации
• Нет захардкоженных токенов, паролей, ключей
• Пользовательский input экранируется
• API-запросы используют авторизацию

Производительность

• Нет ненужных перерендеров (OnPush, memo, trackBy)
• Тяжёлые вычисления мемоизированы (computed, useMemo)
• Нет утечек памяти (отписки от Observable, removeEventListener)
• Большие списки используют virtual scrolling или пагинацию

Архитектура

• Нет дублирования кода (DRY)
• Компонент/функция делает одну вещь (SRP)
• Нет лишней связанности между модулями
• Паттерны проекта соблюдены

Тесты

• Новая логика покрыта тестами
• Тестируются негативные сценарии (ошибки)
• Нет тестов ради тестов (assert true === true)

Как давать фидбек

Плохо vs Хорошо

❌ «Это ужасный код»
✅ «Здесь используется мутация state напрямую — это может привести к багам. Лучше return [...items, newItem]»

❌ «Переделай нормально»
✅ «Предлагаю вынести валидацию в отдельную функцию — будет проще тестировать и переиспользовать»

Правила

1. Критикуй код, не человека — «этот подход может вызвать проблемы» вместо «ты написал плохо»
2. Объясняй почему — не «исправь», а «исправь, потому что при пустом массиве будет ошибка»
3. Предлагай альтернативу — не просто указывай на проблему, а показывай решение
4. Хвали хорошее — замечания запоминаются, а похвала мотивирует

Как автору реагировать на замечания

Не принимайте замечания лично. Ревью кода, а не вас.

Процесс в команде

Сроки

• Ревью — в течение 24 часов
• Автор отвечает — в течение 24 часов
• PR не висит больше 2 дней без прогресса

CODEOWNERS

GitHub позволяет назначить обязательных ревьюеров для частей кодовой базы:

# .github/CODEOWNERS
/src/app/auth/      @team-backend
/src/app/shared/    @senior-devs
/package.json       @tech-lead

Файлы в /src/app/auth/ не смёржатся без аппрува от @team-backend.

Размер PR и качество

Итог

Code Review — не бюрократия, а инструмент. Хорошо отревьюенный PR экономит часы отладки на продакшене. И чем качественнее автор подготовил PR — тем полезнее будет ревью.