Какие антипаттерны вы знаете?

🟢 Junior Level

Антипаттерны — это плохие решения, которые часто повторяются. Похожи на паттерны, но наоборот — вредят, а не помогают.

Частые антипаттерны:

1. God Object (Божественный объект):

// ❌ Один класс делает ВСЁ
public class Application {
    public void connectToDatabase() { }
    public void validateUser() { }
    public void sendEmail() { }
    public void generateReport() { }
    public void backupData() { }
    // ... ещё 1000 методов
}

2. Spaghetti Code:

// ❌ Код без структуры, трудно читать
public void process() {
    if (a) { for (...) { if (b) { ... } } }
    else { while (...) { switch (...) { ... } } }
}

3. Copy-Paste Programming:

// ❌ Один и тот же код в 10 местах
// Изменил в одном — забыл в остальных

Как избежать:

Разделяйте код на маленькие классы
Следуйте SOLID принципам
Не копируйте код — используйте общие методы

🟡 Middle Level

Основные антипаттерны

1. Golden Hammer (Золотой молоток):

// Использование любимого паттерна везде, где можно
// "У меня есть Spring — сделаю всё через бины!"
// Иногда достаточно простого if-else

2. Inner-Platform Effect:

// reinventing wheel внутри приложения
// Своя БД поверх файловой системы
// Свой ORM поверх JDBC

3. Lava Flow:

// Код, который никто не понимает, но боится удалить
// "Не трогай, оно работает"
// → Технический долг растёт

4. Magic Push Button:

// Использование кода, не понимая как работает
// Copy-paste из StackOverflow
// → Баги, которые невозможно отдебажить

5. Poltergeist (Полтергейст):

// Классы без состояния, только для вызова других классов
public class Manager {
    public void doWork() {
        service.process(new Processor().execute());
    }
}
// → Лишний уровень косвенности

Как распознать

Признак	Антипаттерн
Класс > 500 строк	God Object
Метод > 50 строк	Long Method
10+ параметров	Parameter List
Дублирование кода	Copy-Paste
“Не трогай, работает”	Lava Flow

🔴 Senior Level

Архитектурные антипаттерны

1. Big Ball of Mud:

Нет архитектуры, всё связано со всем
→ Изменение в одном месте ломает другое
→ Невозможно тестировать
→ Решение: рефакторинг, модуляризация

2. Architecture by Implosion:

Проектирование от деталей к общему
→ Начали кодить без дизайна
→ Потеряли общую картину

3. Cargo Cult Programming:

// Копирование кода/конфигурации без понимания зачем.
// Например, добавление @Transactional на каждый метод «на всякий случай».
// Или добавление @Service на каждый класс «потому что так принято».

4. Not Invented Here:

"Наше лучше" → переписываем всё с нуля
→ Тратим годы на то, что уже сделано

Организационные антипаттерны

1. Design by Committee:

Слишком много людей принимают решения
→ Компромиссный, неоптимальный дизайн
→ "Верблюд — это лошадь, спроектированная комитетом"

2. Management by Numbers:

Оценка только по метрикам
→ Игнорирование качества кода
→ Технический долг растёт

Антипаттерны в коде

1. Couplet:

// Жёсткая связь двух классов
class A { private B b = new B(); }
class B { private A a = new A(); }
// → Circular dependency

2. God Object (он же Blob):

Один класс делает всё, остальные — только передают данные
→ Нарушение SRP
→ Решение: распределение ответственности

3. Sequential Coupling:

// Методы должны вызываться в строгом порядке
obj.init();
obj.configure();
obj.process();  // Если вызвать без init → exception!
// → Решение: Builder или конструктор

Prevention Strategies

Code Review — ловите антипаттерны до merge
Static Analysis — SonarQube, Checkstyle
Metrics — отслеживайте complexity, duplication
Refactoring — регулярно чистите код
Knowledge Sharing — учите команду

Production Experience

Реальный сценарий: God Object убил проект

Класс UserService: 5000 строк, 200 методов
15 разработчиков concurrently → merge conflicts каждый день
Решение: разделили на 12 классов по SRP
Результат: конфликты исчезли, читаемость значительно повысилась

Best Practices

SOLID — лучшая защита от антипаттернов
KISS — не усложняйте
YAGNI — не делайте “на будущее”
DRY — не копируйте код
Code Review — коллективная ответственность
Refactoring — регулярная чистка
Metrics — измеряйте качество

Резюме для Senior

Антипаттерны = повторяющиеся плохие решения
God Object — самый частый в enterprise
Lava Flow — признак отсутствия Code Review
Golden Hammer — злоупотребление паттернами
Big Ball of Mud — отсутствие архитектуры
SOLID — лучшая профилактика
Metrics — раннее обнаружение проблем
Refactoring — регулярная гигиена кода

🎯 Шпаргалка для интервью

Обязательно знать:

God Object — один класс делает всё (>500 строк, >200 методов), нарушает SRP, решение: разделение по ответственности
Golden Hammer — использование любимого паттерна везде, overengineering убивает читаемость
Lava Flow — код, который никто не понимает, но боится удалить → технический долг растёт
Big Ball of Mud — нет архитектуры, всё связано со всем, невозможно тестировать
Cargo Cult — копирование кода/конфигурации без понимания (@Transactional на каждый метод “на всякий случай”)
Poltergeist — классы без состояния, только для вызова других классов → лишний уровень косвенности
SOLID + KISS + YAGNI + DRY — лучшая профилактика антипаттернов

Частые уточняющие вопросы:

Как распознать God Object? — Класс >500 строк, >200 методов, 15+ разработчиков concurrently → merge conflicts
Что такое Lava Flow и почему опасен? — “Не трогай, оно работает” → никто не понимает код → технический долг растёт
Чем Cargo Cult отличается от Golden Hammer? — Cargo Cult = копирование без понимания, Golden Hammer = злоупотребление паттерном
Как бороться с Big Ball of Mud? — Модуляризация, Code Review, Static Analysis (SonarQube), регулярный рефакторинг

Красные флаги (НЕ говорить):

“У нас один класс на весь сервис” — это God Object, разделение по SRP обязательно
“Я добавляю @Transactional везде для безопасности” — Cargo Cult, ненужный overhead
“Этот код старый, но работает — не трогайте” — Lava Flow, источник багов
“Мне не нужны метрики качества кода” — без метрик антипаттерны растут незаметно

Связанные темы:

[[1. Что такое паттерны проектирования]] — паттерны vs антипаттерны
[[3. Что такое Singleton]] — Singleton как источник антипаттернов
[[6. Каковы проблемы с Singleton]] — проблемы Singleton
[[2. Какие категории паттернов существуют]] — правильные паттерны вместо антипаттернов
[[12. В чём преимущество Decorator перед наследованием]] — композиция как альтернатива God Object