Developer

Code review: что и как проверять

↑ 6.3 Качество кода и тестирование: продвинутый уровень · ← Предыдущая

Желательно~3 мин чтенияУровень: middle

Зачем это на собесе

Review показывает зрелость: как вы даёте и принимаете обратную связь, что считаете важным в изменении.

Что проверять (по приоритету)

  1. Корректность: решает ли задачу, граничные случаи, обработка ошибок.
  2. Дизайн: место кода в архитектуре, связность, дублирование.
  3. Риски: безопасность (XSS, токены в логах), производительность, обратная совместимость API.
  4. Тесты: покрывают ли поведение и регрессии.
  5. Читаемость: имена, размер функций, комментарии «почему».
  6. Стиль — на откуп автоматике (ESLint, Prettier).

Как делать автору

  • маленький PR (до 300–400 строк), одна цель;
  • описание: что, зачем, как проверить, скриншоты;
  • самопроверка перед отправкой;
  • draft PR для раннего фидбека.

Как делать ревьюеру

  • сначала понять контекст, потом искать проблемы;
  • комментарии по коду, а не по человеку; вопросы вместо приказов;
  • различать blocker и nit (nit:, optional:);
  • предлагать конкретное решение;
  • отвечать в разумный срок (SLA, например 1 рабочий день);
  • хвалить хорошие решения.

Автоматизация

CI-проверки (lint, typecheck, тесты), шаблон PR, CODEOWNERS, обязательные approvals, защита ветки.

Вопросы с ответами

Вид графа

Обратные ссылки