Нужно ли прописывать в зависимости CGLIB, который не пригодится в дальнейшем?

Следует ли прописывать CGLIB в зависимостях, если он не пригодится?

Это классический вопрос о управлении зависимостями и архитектуре проекта. Ответ — однозначно НЕ СЛЕДУЕТ, и вот почему.

Принцип YAGNI (You Aren't Gonna Need It)

YAGNI — один из ключевых принципов чистого кода и гибкой разработки. Он гласит: не добавляй функционал или зависимости, которые тебе не нужны сейчас.

// НЕПРАВИЛЬНО — добавляем CGLIB "на всякий случай"
pom.xml:
<dependency>
    <groupId>cglib</groupId>
    <artifactId>cglib</artifactId>
    <version>3.3.0</version>
</dependency>

Почему это плохая практика

1. Увеличение размера JAR файла

• CGLIB добавляет сотни килобайт в итоговый артефакт
• Это влияет на скорость загрузки и развертывания приложения
• В микросервисной архитектуре каждый килобайт имеет значение

2. Усложнение зависимостей

• Дополнительная библиотека создает собственные зависимости
• Возникают потенциальные конфликты версий
• Усложняется управление уязвимостями безопасности

3. Сложность в отладке

• Неиспользуемая зависимость может быть случайно использована
• Это затрудняет поиск проблем в будущем
• Снижает читаемость проекта для новых разработчиков

4. Техдолг

• Каждая ненужная зависимость — это техдолг
• Она требует обновления при выходе новых версий
• Создает ложное впечатление о сложности проекта

Когда CGLIB понадобится

Если CGLIB действительно потребуется, его легко добавить позже:

// Spring AOP — автоматически подтягивает CGLIB при необходимости
@Configuration
@EnableAspectJAutoProxy(proxyTargetClass = true)
public class AopConfig {
    // Spring сам загрузит CGLIB, когда понадобится
}

Лучшие практики управления зависимостями

1. Явные и минимальные зависимости

<dependencies>
    <dependency>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-web</artifactId>
    </dependency>
</dependencies>

2. Регулярный аудит

• Используй mvn dependency:analyze для поиска неиспользуемых зависимостей
• Используй mvn dependency:tree для проверки конфликтов версий

3. Используй зависимости автоматически

• Spring Boot стартеры включают все необходимое
• Явное управление нужно только для специальных случаев

Итоговый ответ

НЕ ПРОПИСЫВАЙ CGLIB в зависимостях, если он не нужен сейчас. Это нарушает принцип YAGNI, загромождает проект и создает техдолг.

Когда CGLIB действительно понадобится, ты легко добавишь его в pom.xml. Правило золотого стандарта: Добавляй зависимость только когда получаешь ошибку класса или явно видишь необходимость в коде.