Які антипатерни ви знаєте?

🟢 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