Какие использовали методы для кросс-ревью

Методы кросс-ревью в разработке

Кросс-ревью (code review) — это процесс проверки кода другими разработчиками перед его интеграцией в основную ветку. Это критически важная практика для обеспечения качества, распределения знаний и предотвращения ошибок.

1. Pull Request / Merge Request подход

GitHub Pull Request — самый распространённый метод:

1. Разработчик создаёт ветку из main
2. Делает коммиты с изменениями
3. Открывает PR с описанием
4. Другие разработчики оставляют комментарии
5. Автор исправляет замечания
6. После одобрения — merge в main

Пример PR описания:

## Описание
Добавлен сервис для отправки email уведомлений

## Что изменилось
- Создан EmailService с поддержкой HTML шаблонов
- Добавлены unit тесты (90% coverage)
- Добавлена интеграция с SendGrid

## Как тестировать
1. Запустить tests: make test
2. Проверить на локальной машине

## Связанные задачи
Fixes #123

2. Сценарии проверки

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

// Ревьюер проверяет: работает ли код как ожидается?
public class UserServiceTest {
    @Test
    void testCreateUser_validInput_success() {
        // Проверяем что пользователь создан корректно
        User user = userService.create("john@example.com", "John");
        assertEquals("john@example.com", user.getEmail());
    }
}

Архитектура и дизайн:

// Ревьюер спрашивает:
// - Это нарушает SOLID принципы?
// - Класс имеет одну ответственность?
// - Правильная архитектурная слоёв?

// ❌ Плохо: Controller напрямую работает с БД
public class UserController {
    @PostMapping
    public void createUser(UserDto dto) {
        database.save(new User(...));  // Нарушает слои
    }
}

// ✅ Хорошо: через Service слой
public class UserController {
    private final UserService service;
    
    @PostMapping
    public void createUser(UserDto dto) {
        service.create(dto);
    }
}

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

// Ревьюер ищет потенциальные проблемы:

// ❌ Плохо: N+1 запрос
for (User user : users) {
    List<Order> orders = database.getOrdersByUserId(user.getId());  // Запрос в цикле!
}

// ✅ Хорошо: один запрос
List<Order> allOrders = database.getOrdersByUserIds(userIds);

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

// ❌ Плохо: SQL инъекция
String query = "SELECT * FROM users WHERE email = " + email;

// ✅ Хорошо: параметризованный запрос
String query = "SELECT * FROM users WHERE email = ?";
preparedStatement.setString(1, email);

3. Чек-листы для ревьюеров

Функциональная логика:

• Код делает что задумано
• Обработаны все edge cases
• Нет магических чисел
• Понятные имена переменных

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

• Есть unit тесты
• Coverage >= 80%
• Граничные случаи протестированы
• Нет flaky тестов

Архитектура:

• Соблюдены слои архитектуры
• Нет циклических зависимостей
• SOLID принципы соблюдены
• Кодовая база не усложняется

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

• Нет O(n²) алгоритмов где нужны O(n)
• Нет утечек памяти
• DB запросы оптимальны

4. Инструменты и процесс

GitHub Actions автоматизация:

name: Code Review Checks
on: [pull_request]
jobs:
  tests:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2
      - name: Run tests
        run: make test
      - name: Check coverage
        run: make coverage
      - name: Lint code
        run: make lint

Комментирование кода:

Ревьюер может:
✓ Оставить комментарий на строку
✓ Запросить изменения (Request changes)
✓ Одобрить (Approve)
✓ Дать рекомендацию (Comment)

5. Обсуждение и правила

Требования для merge:

• Минимум 2 одобрения от разных разработчиков
• Все автоматические проверки прошли (CI/CD)
• Конфликты слиты с main
• Описание соответствует изменениям

Культура ревью:

✓ Конструктивная критика ("Рассмотри использовать X вместо Y")
✓ Совместное решение проблем
✓ Обучение через комментарии

✗ Личная критика
✗ Требование идеального кода
✗ Блокировка без обоснования

6. Типичные замечания

Типичные Issues:

• Отсутствие javadoc на public методах
• Игнорирование warnings в IDE
• Слишком большой класс (> 200 строк)
• Не обработаны исключения
• Хардкод вместо конфигурации

// Ревьюер просит добавить документацию
/**
 * Создаёт нового пользователя
 * @param email email пользователя
 * @param name полное имя
 * @return созданный пользователь
 * @throws IllegalArgumentException если email некорректный
 */
public User createUser(String email, String name) {
    // ...
}

Преимущества кросс-ревью

• Качество — меньше багов доходит в production
• Обучение — junior разработчики учатся от senior
• Знание кода — команда знает весь codbase
• Стандарты — единый стиль и подход
• Ответственность — код проверен несколькими людьми

Эффективное code review — это инвестиция в качество и долгосрочное здоровье проекта.