Code review в Java: что проверять и как давать обратную связь

Code review в Java: что проверять и как давать обратную связь

Code review (ревью кода) — это один из самых эффективных инструментов повышения качества программного продукта и профессионального роста команды. Однако, когда дело доходит до Java, многие разработчики (особенно джуниоры) либо боятся отправлять свой код на ревью, либо не знают, на что обращать внимание при проверке чужого кода. В этой статье мы разберём, что именно нужно проверять в Java-коде и как формулировать замечания, чтобы не обидеть коллегу, а помочь ему стать лучше.

1. Что проверять в Java-коде: технический чек-лист

Первое, что приходит в голову — это синтаксис и логика. Но профессиональное ревью выходит далеко за эти рамки. Вот ключевые аспекты, которые стоит проверять в каждом пулл-реквесте.

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

Посмотрите, насколько хорошо новое изменение вписывается в существующую архитектуру. Нарушает ли оно принципы SOLID? Например, если вы видите класс, который делает слишком много (God Object), это повод предложить его разбить.

• Принцип единственной ответственности (SRP): Каждый класс должен иметь одну причину для изменения.
• Инверсия зависимостей (DIP): Зависите от абстракций, а не от конкретных реализаций.
• Паттерны: Использование синглтонов, фабрик или стратегий должно быть оправдано, а не применено "на всякий случай".

// Плохо: класс знает и о логике, и о сохранении
public class UserService {
    public void registerUser(String name) {
        // валидация
        // сохранение в БД
        // отправка email
    }
}

// Хорошо: разделение ответственности
public class UserService {
    private final UserRepository repository;
    private final EmailService emailService;

    public void registerUser(String name) {
        User user = new User(name);
        repository.save(user);
        emailService.sendWelcome(user);
    }
}

1.2. Производительность и работа с памятью

Java — язык с автоматическим управлением памятью, но это не значит, что можно забыть об оптимизации. Проверяйте:

• Конкатенация строк в цикле: Используйте StringBuilder или StringBuffer.
• Лишние объекты: Создание временных объектов в горячих циклах.
• Коллекции: Выбор правильной реализации (например, ArrayList против LinkedList).
• NullPointerException: Используйте Optional или проверки на null.

// Плохо: миллион строк в памяти
String result = "";
for (String s : list) {
    result += s;
}

// Хорошо: StringBuilder
StringBuilder sb = new StringBuilder();
for (String s : list) {
    sb.append(s);
}
String result = sb.toString();

1.3. Обработка ошибок и исключений

Ошибка в Java — это не всегда баг. Иногда это неправильное использование исключений. Обратите внимание:

• Пустые catch-блоки: catch (Exception e) {} — это зло. Ошибку нужно хотя бы залогировать.
• Слишком общие исключения: Ловить Exception или Throwable — плохая практика.
• Потоки ресурсов: Используйте try-with-resources для автоматического закрытия.

// Плохо: глотаем исключение
try {
    // какой-то код
} catch (Exception e) {
    // ничего не делаем
}

// Хорошо: логируем и пробрасываем дальше
try {
    // какой-то код
} catch (SQLException e) {
    log.error("Ошибка при работе с БД", e);
    throw new ServiceException("Не удалось выполнить операцию", e);
}

1.4. Тесты и покрытие

Ревью кода без проверки тестов — это ревью "наполовину". Убедитесь, что:

• Написаны unit-тесты для новой логики.
• Тесты зелёные и не зависят от внешних факторов (БД, сеть).
• Нет закомментированных тестов — это признак "сломанной" функциональности.

2. Как давать обратную связь: психология и этика

Теперь, когда вы знаете, что проверять, давайте поговорим о как. Даже самый правильный комментарий может быть воспринят в штыки, если его неправильно подать.

2.1. Формулируйте замечания как предложения, а не приказы

Вместо "Это неправильно, переделай" используйте "Что думаешь насчёт...?" или "Предлагаю рассмотреть альтернативу...". Это снижает напряжение и превращает ревью в диалог.

❌ "Ты должен использовать StringBuilder здесь."
✅ "Я заметил конкатенацию строк в цикле. Возможно, стоит использовать StringBuilder для улучшения производительности?"

2.2. Разделяйте "критично" и "ничего страшного"

Не все замечания одинаково важны. Есть критические ошибки (баги, утечки памяти) и есть стилистические предпочтения. Используйте метки или префиксы:

• Blocker: Код не скомпилируется или сломает продакшн.
• Major: Нарушение архитектуры или производительности.
• Minor: Стиль, нейминг, форматирование.
• Nitpick: Личное мнение, можно не исправлять.

2.3. Хвалите хорошие решения

Code review — это не только поиск ошибок. Если вы видите элегантное решение или чистый код, обязательно отметьте это. Это мотивирует разработчика и показывает, что вы внимательно читаете его код.

// Пример хорошего комментария
// "Отличное использование Stream API! Код стал гораздо читаемее."

3. Типичные ошибки при code review в Java

Даже опытные разработчики иногда допускают ошибки в процессе ревью. Вот что стоит избегать:

• Микроменеджмент: Не исправляйте каждую