Как проводилось код-ревью в команде

# Как проводилось код-ревью в команде

Что такое код-ревью

Это процесс, когда другие разработчики проверяют твой код перед тем как его залить в main. Цель:

• Найти баги до production
• Поделиться знаниями в команде
• Улучшить качество кода
• Предотвратить технический долг

Как это работает в реальной команде

Шаг 1: Создаешь Pull Request (PR)

Ты завершил фичу и отправил её на review:

1. Создаёшь branch: git checkout -b feature/user-authentication
2. Пишешь код + тесты
3. Коммитишь: git commit -m "Add JWT authentication"
4. Отправляешь: git push origin feature/user-authentication
5. Создаёшь PR на GitHub/GitLab/Bitbucket

Шаг 2: Описание PR

Хорошее описание PR выглядит так:

## Что было сделано
Добавлена аутентификация через JWT токены

## Почему
Улучшает безопасность API, позволяет отказаться от session-based auth

## Как тестировать
1. POST /api/auth/login с credentials
2. Получаешь JWT токен
3. Используй токен в Authorization header

## Checklist
- [x] Написаны unit тесты (coverage > 80%)
- [x] Написаны integration тесты
- [x] Обновлена документация
- [x] Нет console.log и TODO комментариев
- [x] Код не имеет избыточной сложности

## Скриншоты (если UI)
[Было] → [Стало]

Шаг 3: Код-ревью от других разработчиков

Senior или Middle разработчики проверяют:

1. ПРАВИЛЬНОСТЬ
   Логика соответствует requirements
   Ошибки обработаны
   SQL безопасен (нет injection)
   
2. ПРОИЗВОДИТЕЛЬНОСТЬ
   Нет N+1 проблем
   Индексы добавлены
   Логирование не слишком verbose
   
3. БЕЗОПАСНОСТЬ
   Валидация на входе
   RBAC проверки
   Секреты не хардкодированы
   
4. КАЧЕСТВО КОДА
   Соответствует code style
   DRY принципы
   SOLID принципы
   Читаемость хорошая
   
5. ТЕСТИРОВАНИЕ
   Тесты покрывают happy path
   Тесты покрывают edge cases
   Coverage > 80%

Примеры комментариев при ревью

Пример 1: Проблема с производительностью

Код разработчика:

@GetMapping("/users")
public List<UserDTO> getUsers() {
    List<User> users = userRepository.findAll();
    
    List<UserDTO> dtos = new ArrayList<>();
    for (User user : users) {
        List<Order> orders = orderRepository.findByUserId(user.getId());
        UserDTO dto = UserConverter.toDTO(user, orders);
        dtos.add(dto);
    }
    return dtos;
}

Комментарий ревьюера: N+1 problem detected. Используй JOIN для загрузки заказов вместе с пользователями.

Пример 2: Безопасность

Код разработчика:

@PostMapping("/create-account")
public void createAccount(@RequestBody CreateUserRequest request) {
    User user = new User();
    user.setEmail(request.getEmail());
    user.setPassword(request.getPassword());
    userRepository.save(user);
}

Комментарий ревьюера: Пароль не должен сохраняться в открытом виде. Используй PasswordEncoder.encode().

Пример 3: Читаемость кода

Код разработчика:

public int calc(List<Order> o, int t) {
    int r = 0;
    for (int i = 0; i < o.size(); i++) {
        if (o.get(i).getS() == 1 && o.get(i).getA() > t) {
            r += o.get(i).getA();
        }
    }
    return r;
}

Комментарий ревьюера: Переименуй переменные. o -> orders, t -> minAmount, r -> totalAmount. Также используй Stream API.

Как разработчик отвечает на комментарии

Вариант 1: Согласен и исправляю

Ревьюер: N+1 problem detected Разработчик: Исправил. Посмотри последний commit.

Вариант 2: Не согласен и объясняю

Ревьюер: Зачем ReentrantLock, просто используй synchronized. Разработчик: ReentrantLock позволяет tryLock с таймаутом. Это нужно для обработки timeout в нашем случае. Ревьюер: Fair point. LGTM.

Процесс до мерджа в main

1. Разработчик создает PR
2. CI пайплайн запускает тесты и линтер
3. Reviewer проверяет код
4. Reviewer оставляет комментарии
5. Разработчик исправляет
6. Reviewer approves
7. Разработчик мержит в main
8. CD пайплайн деплоит в staging/production

Культура ревью в хорошей команде

Что ДЕЛАЕТСЯ:

• Объективные комментарии ("Этот индекс улучшит производительность в 10 раз")
• Помощь Junior разработчикам
• Похвала хорошему коду
• Обсуждение trade-offs

Что НЕ ДЕЛАЕТСЯ:

• Личные атаки
• Требование идеального кода
• Bike-shedding по деталям
• Затягивание ревью

Инструменты для ревью

• GitHub/GitLab/Bitbucket с встроенными комментариями
• SonarQube/CodeClimate для автоматического анализа
• Линтеры (checkstyle, sonarqube)
• Автоматические тесты в CI

Как подготовиться к ревью

Перед созданием PR:

1. Запусти тесты: mvn test
2. Запусти линтер: mvn checkstyle:check
3. Сделай self-review
4. Напиши хорошее описание PR
5. Добавь тесты (coverage > 80%)
6. Проверь на security

Совет для собеседования

Если спросят про код-ревью, ответь:

Мы использовали GitHub Pull Requests. Процесс был:

1. Разработчик создает PR с описанием
2. CI автоматически запускает тесты и линтер
3. 1-2 Senior/Middle разработчика проверяют код
4. Обсуждаем trade-offs если есть
5. Разработчик исправляет замечания
6. Reviewer approves и мержит

Основной фокус был на:

• Производительность (N+1, индексы)
• Безопасность (валидация, SQL injection)
• Качество кода (читаемость, SOLID)
• Тестирование (coverage > 80%)

Важно что это была культура помощи, а не критики. Мы помогали друг другу расти.