Код-ревью при загруженной команде

Решение

1. Организация процесса код-ревью при ограниченных ресурсах

Понимание проблемы

Это не просто задача о код-ревью. Это баланс между:

• Необходимостью: нужно оценить код для планирования
• Ограничениями: team загружена, есть только один джуниор
• Рисками: если джуниор делает ревью сам, может пропустить issues

Стратегия: Layered approach

Фаза 1: Подготовка джуниора (День 1-2)

**Цель:**让 джуниор может провести базовый анализ, который сэкономит время для seniors.

Действия:

• Провести 2-часовой training session с lead dev'ом (один раз, не постоянное отвлечение)

• Темы training:

  • Архитектура проекта (overview)
  • Какие паттерны используются
  • Common anti-patterns в этой codebase
  • Что ревьер ищет: security, performance, readability, duplication, edge cases
  • Инструменты: SonarQube, ESLint, other linters уже настроены?

• Создать checklist для джуниора (простой, очевидный):

  - [ ] Code compiles/runs без errors
  - [ ] Variable names понятны (не a, b, temp)
  - [ ] Functions не слишком длинные (>50 строк - требует escalation)
  - [ ] Comments есть для non-obvious code
  - [ ] No hardcoded values (IDs, passwords, URLs)
  - [ ] Tests есть если expected
  - [ ] No console.log/print statements left
  - [ ] Error handling есть где нужно
  - [ ] No obvious security issues (SQL injection, XSS)
  - [ ] No obvious duplicated code vs existing code
  

• Дать несколько примеров:

  • Хороший PR из старого проекта
  • Плохой PR с issues
  • Как написать комментарий при ревью

Фаза 2: Автоматизированный скрининг (параллельно)

Цель: убрать очевидные issues до human review.

Действия:

• Настроить линтеры если ещё не настроены:

  • ESLint для JavaScript
  • Prettier для форматирования
  • SonarQube для code quality
  • Security scanners (Snyk, WhiteSource)

• Запустить автоматические checks на всей codebase

  • Результат: отчёт о найденных issues
  • Нужно ли refactoring?

• Результат: список автоматических issues к fixing, джуниор может помочь исправить

Фаза 3: Джуниор делает первый pass (День 3-5)

Цель: джуниор находит очевидные issues и пропускает сложные на seniors.

Процесс:

• Джуниор проходит код файл за файлом
• Делает notes в spreadsheet:

  File | Line | Issue | Severity (auto/minor/major) | Comment
  utils.js | 45 | Variable 'x' should be 'index' | minor | Readability
  api.js | 120 | No error handling for fetch | major | Could crash
  

• Ищет patterns которые знает (по checklist)
• Для сложного кода: отмечает как "needs senior review" и переходит дальше
• Не застревает на одном файле больше 30 минут

Дополнительные обязанности джуниора:

• Проверить на очевидные дублирования (compare с существующим код)
• Посчитать метрики: сколько функций, строк, complexity
• Составить список проблемных файлов: какие требуют больше внимания

Фаза 4: Senior ревью на высокоуровне (День 6-7)

Цель: seniors фокусируются на важном, пропускают очевидное.

Подход:

• Джуниор подготовил список issues (minor issues) и список проблемных файлов (major concerns)
• Senior берёт только проблемные файлы:
  • Architecture decisions
  • Security-critical code
  • Performance-sensitive code
  • Complex algorithms
• Senior смотрит 30 минут в file, даёт high-level feedback
  • "Эта архитектура не масштабируется"
  • "Здесь security issue"
  • "Нужно рефакторить это вот так"
• Senior не тратит время на "переименовать переменную", это уже знает джуниор

Фаза 5: Джуниор второй pass + Compilation list (День 8)

Цель: собрать финальный отчёт.

Действия:

• Джуниор incorporates feedback от seniors
• Группирует issues по категориям:
  • Critical: Security, data loss, crashes
  • Major: Architecture, performance, maintainability
  • Minor: Naming, formatting, comments
• Составляет recommendations:
  • Какие файлы нужно рефакторить
  • Какие технологии нужно обновить
  • Какие процессы ввести (e.g., linting, code review)

2. Задачи для джуниора

ЧТО делегировать (безопасно)

✅ МОЖНО делегировать:

1. Автоматизированные checks

   • Запустить лinters на codebase
   • Смотреть отчёты SonarQube
   • Документировать findings
   • Ок если пропустит что-то, автоматизация не подведёт

2. Surface-level reviews

   • Naming conventions
   • Formatting и style
   • Missing comments
   • Obvious duplication
   • No hardcoded values
   • Console.log statements
   • Риск: может пропустить контекст, но это ОК

3. Metrics gathering

   • Посчитать LOC (lines of code)
   • Complexity metrics
   • Number of functions/classes
   • Cyclomatic complexity (инструменты считают)
   • Это объективная информация

4. Documentation

   • Создать структуру report
   • Категоризировать findings
   • Оформить в readable format
   • Это не требует expertise

5. Research tasks

   • "В этом коде используется library X, проверь есть ли updates"
   • "Посмотри есть ли лучший способ сделать Y в современных версиях"
   • "Сравни это с best practices"
   • Джуниор читает docs, делает выводы, seniors одобрят

6. Simple refactoring

   • Переименовать переменные по feedback
   • Убрать console.logs
   • Форматировать код (prettier, автоматизировано)
   • Добавить comments
   • Это механическая работа, джуниор не испортит

❌ НЕ делегировать:

1. Architecture decisions

   • "Должна ли это быть microservice или monolith?"
   • "Правильный ли паттерн использован?"
   • Джуниор не имеет опыта

2. Security审查

   • SQL injection, XSS, auth issues
   • Джуниор может заметить obvious issues, но может пропустить subtle ones
   • Senior review обязателен

3. Performance analysis

   • "Почему это медленно?"
   • Требует опыта и tools
   • Джуниор может собрать metrics, senior анализирует

4. Complex algorithm review

   • Правильна ли логика?
   • Edge cases?
   • Требует expertise

5. Overall verdict

   • Годен ли код для production?
   • Какие риски?
   • Senior decision

Процесс делегирования

Джуниор: Смотрит код с checklist
   ↓
Джуниор: Находит obvious issues + собирает metrics
   ↓
Джуниор: Отмечает что требует senior attention
   ↓
Senior: Смотрит только flagged items + architecture
   ↓
Senior: Даёт feedback
   ↓
Джуниор: Incorporates feedback, компилирует отчёт
   ↓
Senior: Approves отчёт (20 минут)

3. Минимизация отвлечения seniors

Стратегия 1: Батчинг (batch processing)

• Вместо "Эй, посмотри этот файл", джуниор собирает вопросы
• Один раз в день или раз в 2 дня: 30-минутная встреча
• Все вопросы за раз
• Senior отвечает на все, потом снова работает
• Результат: seniors не interrupted, focus time не ломается

Стратегия 2: Асинхронная коммуникация

• Джуниор пишет notes в shared doc/spreadsheet
• Senior читает когда есть время
• Комментит в doc: "Согласен", "Это security issue, нужно переделать так"
• Async review экономит встречи

Стратегия 3: Защита time blocks

• Договориться с team:
  • 10:00-11:00: No interruptions (critical work time)
  • 14:00-15:00: Available for code review questions
  • Остальное время: focus
• Джуниор знает когда может спросить, когда нет

Стратегия 4: Инструменты вместо людей

• Запустить linters/static analysis
  • ESLint, Prettier, SonarQube, Snyk
  • Они найдут 80% obvious issues
  • Senior не нужно смотреть на это вручную
• Результат: seniors ревьют только complex stuff

Стратегия 5: Парное программирование (экономно)

• Не 8 часов в день
• 1-2 часа на критических файлах
• Джуниор и senior вместе
• Senior говорит: "Видишь, так мы решаем эту проблему"
• Джуниор учится, потом может делать сам
• Экономия: senior объясняет один раз вместо 5 раз

Стратегия 6: Правильные expectations

• Объяснить seniors:
  • "Джуниор делает первый pass, вы делаете высокоуровневый ревью"
  • "Это займёт 2-3 часа вашего времени, не 20"
  • "Это временно, нужно для оценки нового проекта"
• Senior видит light end of tunnel

4. Итоговый timeline

День 1-2:  Training джуниора + setup инструментов
День 3-5:  Джуниор делает первый pass (асинхронно, no blockers)
День 6-7:  Senior ревью flagged items (2-3 часа)
День 8:    Джуниор компилирует отчёт + senior approves (1 час)

Total senior time: ~6 часов вместо 40 часов если бы senior делал всё сам.

5. Выход: Итоговый отчёт

Джуниор подготавливает отчёт с:

1. Summary

• Общие metrics (LOC, functions, complexity)
• High-level findings
• Risk assessment

2. Issues categorized

• Critical (3-5 items)
• Major (10-15 items)
• Minor (30+ items)

3. Recommendations

• Какие части нужно рефакторить
• Какие инструменты установить
• Какие процессы ввести
• Estimated effort

4. Plan forward

• Phase 1: Fix critical issues (2 недели)
• Phase 2: Major refactoring (1-2 месяца)
• Phase 3: Ongoing improvements

Итог

Проблема не в том что джуниор не может делать ревью. Проблема в том что senior некогда. Решение: использовать джуниора для скрининга (очевидные issues), senior для expertise (architecture, security, complex logic), инструменты для автоматизации (linters). Это экономит 70-80% senior time, даёт хороший отчёт для планирования, и джуниор учится. Win-win.