Какие знаешь критерии оценки кода?

Критерии оценки кода в Java

В своей практике я оцениваю код по нескольким ключевым измерениям, которые обеспечивают его качество, maintainability и production-readiness.

1. Чистота и читаемость (Readability)

Это первое, что смотрю при code review. Код пишется один раз, но читается много раз. Основные критерии:

• Понятные имена переменных, методов и классов — должны быть self-documenting. Избегаю однобуквенных переменных (кроме loop counters), неинформативных названий типа data, temp
• Правильное форматирование — отступы, длина строк (я придерживаюсь 100-120 символов), расстояния между блоками
• Комментарии — пишу их для сложной бизнес-логики и «почему?», а не «что?». Код должен показывать что, комментарии объясняют почему

// ❌ Плохо
List<String> l = new ArrayList<>();
for(int i = 0; i < arr.length; i++) {
    if(arr[i] > 0) l.add(String.valueOf(arr[i]));
}

// ✅ Хорошо
List<String> positiveNumbers = new ArrayList<>();
for (int number : numbers) {
    if (number > 0) {
        positiveNumbers.add(String.valueOf(number));
    }
}

2. Архитектура и дизайн (Design)

• SOLID принципы — Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion. Код должен быть расширяем и слабо связан
• Правильная иерархия классов — правильное использование наследования vs composition
• Паттерны проектирования — применяю их осознанно, когда они решают реальную проблему, не для галочки
• Разделение concerns — бизнес-логика отделена от инфраструктуры, presentation layer не должна содержать бизнес-правил

// ❌ Плохо — нарушение SRP
public class UserService {
    public void saveUser(User user) {
        // сохранение в БД
        // отправка email
        // логирование
    }
}

// ✅ Хорошо — разделены ответственности
public class UserService {
    private UserRepository repository;
    private EmailService emailService;
    
    public void saveUser(User user) {
        repository.save(user);
        emailService.sendWelcomeEmail(user);
    }
}

3. Производительность (Performance)

• Сложность алгоритмов — анализирую O(n), O(n²), используется ли правильная структура данных
• Memory утечки — проверяю правильность работы с ресурсами, использование try-with-resources
• Избегание unnecessary объектов — не создаю новые объекты в циклах без надобности
• Правильное использование коллекций — HashMap vs TreeMap, ArrayList vs LinkedList в зависимости от use case

// ❌ Плохо
String result = "";
for (String item : items) {
    result += item; // создаёт новый String каждую итерацию
}

// ✅ Хорошо
StringBuilder result = new StringBuilder();
for (String item : items) {
    result.append(item);
}
return result.toString();

4. Тестируемость (Testability)

• Unit test coverage — минимум 80% для критичного кода
• Dependency Injection — зависимости передаются через конструктор, легче mocить в тестах
• Отсутствие сложных взаимозависимостей — код должен быть модульным
• Правильное использование mocks и stubs — тесты проверяют behaviour, а не implementation details

// ❌ Плохо — сложно тестировать
public class PaymentProcessor {
    public void process(Order order) {
        Database db = new Database(); // tight coupling
        db.save(order);
    }
}

// ✅ Хорошо — легко тестировать
public class PaymentProcessor {
    private OrderRepository repository;
    
    public PaymentProcessor(OrderRepository repository) {
        this.repository = repository;
    }
    
    public void process(Order order) {
        repository.save(order);
    }
}

5. Error Handling и безопасность

• Правильная обработка исключений — не catching Exception, не игнорирование ошибок
• Validation input — проверяю граничные значения, null-checks
• Secure coding practices — нет SQL injection, нет hardcoded credentials
• Логирование значимых событий — с нужным level (ERROR для ошибок, DEBUG для detalей)

// ❌ Плохо
try {
    processData(data);
} catch (Exception e) { }

// ✅ Хорошо
try {
    processData(data);
} catch (DataValidationException e) {
    logger.error("Invalid data format", e);
    throw new ApplicationException("Could not process data", e);
} catch (DatabaseException e) {
    logger.error("Database error occurred", e);
    throw new SystemException("System unavailable", e);
}

6. Документация и maintainability

• JavaDoc для public API — что делает метод, какие параметры, что возвращает
• README в проекте — как запустить, архитектура на высоком уровне
• Отсутствие dead code — удаляю неиспользуемые классы и методы
• Version control practices — понятные commit messages, логичная история

7. Compliance и conventions

• Adherence к code style guide — используются linters (Checkstyle, Spotbugs)
• Java conventions — классы CapitalCase, методы camelCase, константы UPPER_CASE
• Framework best practices — если используется Spring, следую его рекомендациям

Инструменты для оценки

В моей практике я использую:

• SonarQube — анализ запахов кода, security issues, code coverage
• Checkstyle — style guide violations
• SpotBugs — потенциальные баги
• JaCoCo — code coverage metrics
• IDE inspections — IntelliJ IDEA имеет встроенные инспекции качества

Важно помнить: все эти критерии работают вместе. Код может быть красивым, но неэффективным. Или производительным, но нечитаемым. Хороший код находит баланс между всеми этими аспектами в контексте конкретного проекта.