Есть ли список требований к коду для Code Review?

Список требований к коду для Code Review

Code Review — это систематическая проверка исходного кода перед тем, как он попадёт в основную ветку. Наличие четкого чек-листа требований — признак профессиональной разработки и гарантирует качество кода в production.

Структурированный чек-лист для Code Review

Функциональность

• Код решает заявленную задачу полностью
• Реализованы все требования из тикета/issue
• Нет регрессии (старая функциональность не сломалась)
• Граничные случаи обработаны (null, пустые массивы, ошибки)
• Изменения логичны и минимальны (no scope creep)

Качество кода

SOLID принципы

• Single Responsibility: каждый класс/функция имеет одну задачу
• Open/Closed: открыт для расширения, закрыт для модификации
• Liskov Substitution: подтипы заменяемы базовыми
• Interface Segregation: узкие интерфейсы, не общие
• Dependency Inversion: зависимости через абстракции, не конкреты

DRY, KISS, YAGNI

• Нет дублирования кода (DRY)
• Решение просто и понятно (KISS)
• Нет функционала "на будущее" (YAGNI)
• Удалены commented-out код и неиспользуемые импорты

Читаемость и именование

• Имена переменных, функций, классов понятны и значимы
• Нет магических чисел и строк (используй константы)
• Длина функций разумна (не более 100 строк)
• Сложные алгоритмы задокументированы
• Форматирование консистентно

TypeScript и типизация

• Нет any типов (или обоснованы)
• Все функции типизированы (параметры и возвращаемые значения)
• Props компонентов имеют интерфейсы
• Union типы используются вместо boolean параметров
• Типы не дублируются (используй reusable типы)

// ❌ Плохо
function processUser(user: any) { }
function validateEmail(email): boolean { }

// ✅ Хорошо
function processUser(user: User): void { }
function validateEmail(email: string): boolean { }

Архитектура

• Слои соблюдены (presentation → application → domain → infrastructure)
• Зависимости направлены правильно (внутрь слоёв)
• Нет циклических зависимостей
• Database access только через services/repositories
• Бизнес-логика отделена от фреймворка

// ❌ Плохо — прямой доступ к БД из handler
app.get('/users/:id', async (req, res) => {
  const user = await db.query('SELECT * FROM users WHERE id = $1', [req.params.id]);
  res.json(user);
});

// ✅ Хорошо — через service
app.get('/users/:id', async (req, res) => {
  const user = await userService.getUserById(req.params.id);
  res.json(user);
});

Тестирование

• Новая функциональность покрыта тестами
• Coverage остаётся >= 90%
• Тесты описывают поведение, а не реализацию
• Нет flaky тестов (которые иногда падают)
• Тесты быстрые (< 100ms на тест в среднем)
• Мокируются внешние зависимости (API, DB)
• Граничные случаи протестированы

// ❌ Плохо — тест описывает реализацию
test('calls findById on repository', () => {
  const repo = jest.mock();
  userService.getUser('123');
  expect(repo.findById).toHaveBeenCalledWith('123');
});

// ✅ Хорошо — тест описывает поведение
test('returns user with correct id', async () => {
  const user = await userService.getUser('123');
  expect(user.id).toBe('123');
  expect(user.name).toBeDefined();
});

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

• Нет hardcoded секретов (API ключи, пароли)
• Входные данные валидируются
• Защита от SQL injection (используй параметризованные запросы)
• Защита от XSS (санитизируй пользовательский ввод)
• Нет логирования чувствительных данных
• Используются переменные окружения для конфигурации
• Правильные статус коды ошибок (не 500 для валидации)

// ❌ Плохо — SQL injection уязвимость
const user = await db.query(`SELECT * FROM users WHERE id = ${req.query.id}`);

// ✅ Хорошо — параметризованный запрос
const user = await db.query('SELECT * FROM users WHERE id = @userId', { 
  userId: req.query.id 
});

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

• Нет N+1 запросов к БД
• Используются индексы для частых запросов
• Циклические операции оптимизированы
• Не блокирующие операции используют async/await
• Большие объекты не копируются без необходимости

// ❌ Плохо — N+1 запросы
const users = await db.query('SELECT * FROM users');
for (const user of users) {
  user.posts = await db.query('SELECT * FROM posts WHERE user_id = @id', { id: user.id });
}

// ✅ Хорошо — один запрос с JOIN
const users = await db.query(`
  SELECT u.*, json_agg(p.*) as posts 
  FROM users u 
  LEFT JOIN posts p ON u.id = p.user_id 
  GROUP BY u.id
`);

Логирование и обработка ошибок

• Логируются важные события (создание, обновление, ошибки)
• Нет дублирования логирования ошибок на разных уровнях
• Ошибки обрабатываются (не тихо падают)
• Используются правильные уровни логирования (info, warn, error)
• Контекст логирования полезен для отладки

// ❌ Плохо — дублирование логирования
try {
  await userService.create(data);
} catch (error) {
  logger.error('Failed to create user', error);
  throw error; // Error уже залоггирован в service
}

// ✅ Хорошо — логирование на одном уровне
try {
  const user = await userService.create(data);
  logger.info('User created', { userId: user.id });
  return user;
} catch (error) {
  logger.error('Failed to create user', error);
  throw error;
}

Работа с базой данных

• Используются миграции для всех изменений схемы
• Миграции протестированы (откат и накат работают)
• SQLAlchemy модели синхронизированы с миграциями
• Используются TIMESTAMPTZ для timestamp полей
• Datetime всегда в UTC с timezone
• Нет race conditions (используется SELECT FOR UPDATE где нужно)

Комментарии и документация

• Публичные функции имеют JSDoc
• Нетривиальная логика задокументирована
• Комментарии объясняют почему, не что
• README обновлён если нужно
• API документация актуальна

Git и коммиты

• Коммиты атомарные (одна логическая единица = один коммит)
• Сообщения коммитов описательные и на русском/английском
• Не более 100 строк изменений в PR (если можно разбить)
• История коммитов чистая (не 50 коммитов с "fix" сообщениями)

# ❌ Плохо
commit: "fixes"
commit: "another fix"
commit: "works now"

# ✅ Хорошо
commit: "feat: добавить кэширование результатов поиска пользователей"
commit: "test: добавить тесты для поиска с фильтрами"
commit: "refactor: извлечь QueryBuilder в отдельный класс"

Backend-специфичные требования

• REST API следует соглашениям (существительные во множественном числе)
• Используется правильный HTTP метод (GET/POST/PUT/DELETE)
• Возвращаются правильные статус коды (200/201/204/400/404/500)
• API версионируется (/api/v1/, /api/v2/)
• Trailing slashes консистентны (без них)
• Pagination реализована для больших коллекций
• Rate limiting где нужно
• CORS настроена правильно

Чек-лист перед отправкой

• Локально всё компилируется и работает
• make lint проходит без ошибок
• make test проходит (тесты не flaky)
• Test coverage >= 90%
• Нет console.log() и commented code
• Нет secrets в коде (.env файлы)
• Dependencies обновлены или добавлены с хорошей причиной

Как проводить Code Review эффективно

Структурированный процесс:

1. Функциональность — работает ли это?
2. Качество — хорош ли код?
3. Безопасность — есть ли уязвимости?
4. Производительность — эффективно ли это?
5. Стиль — соответствует ли стандартам проекта?

Позитивный тон:

# ❌ Плохо
"Это неправильно. Используй правильный паттерн."

# ✅ Хорошо
"Интересный подход! Мы обычно используем это, потому что..."

Профессиональный Code Review — это не критика, а способ улучшить качество кода и развить junior-разработчиков.