Антипаттерны проектирования ПО
Архитектурные антипаттерны — распространенные ошибки в проектировании систем, которые приводят к проблемам в производительности, поддержке и масштабируемости.
Возникают из-за неправильного понимания требований, недостатка опыта или давления сроков.
Существует около 20–30 известных антипаттернов. Рассмотрим некоторые из них.
Большой комок грязи (Big Ball of Mud)
Неорганизованная, беспорядочная архитектура без четкой структуры.
- Причины: отсутствие долгосрочного планирования, рост системы без рефакторинга и учета архитектурных принципов.
- Пример: проект, где новые функции добавляются без раз деления компонентов, создавая хаос и трудности в поддержке.
Код-спагетти (Spaghetti Code)
Код с многочисленными запутанными зависимостями, который сложно поддерживать и тестировать.
- Причины: плохая структурированность, спешка в разработке, отсутствие документации.
- Пример: старый проект, где нет модульности, а изменения в одном месте приводят к сбоям в других частях.
Замечание: Spaghetti Code описывает проблемы на уровне отдельных модулей, а Big Ball of Mud — на уровне архитектуры.
Золотой молоток (Golden Hammer)
Использование одного инструмента или технологии для решения всех задач.
- Причины: ограниченное знание технологий, привычка к одному инструменту.
- Пример: применение SQL для всех видов хранения данных, даже когда NoSQL подходит лучше.
Изобретение велосипеда (Reinventing the Wheel)
Создание собственного решения для задачи, уже решенной готовыми библиотеками или фреймворками.
- Причины: недостаток знаний о существующих решениях.
- Пример: создание собственной системы логирования вместо использования Log4j.
Дымоход (Stovepipe System)
Набор изолированных систем, которые плохо взаимодействуют друг с другом.
- Причины: отсутствие координации между командами, историческое наследие.
- Пример: отделы разрабатывают свои ИТ-системы без учета интеграции с другими.
Божественный объект (God Object)
Один объект, который знает слишком много или делает слишком много.
- Причины: недостаточное разделение ответственности, централизованное управление.
- Пример: класс в ООП, который содержит логику для всего приложения.
Лавина изменений (Lava Flow)
Неиспользуемый или мертвый код остается в проекте.
- Причины: боязнь сломать систему, отсутствие документации.
- Пример: код, написанный в начале проекта, но не удаленный после изменения требований.
Незакрытые соединения (Resource Leak)
Системные ресурсы (например, память или соединения) не освобождаются после использования.
- Причины: ошибки в управлении ресурсами, отсутствие тестирования.
- Пример: открытые сетевые соединения, которые не закрываются.
Избыточная абстракция (Abstract Obsession)
Усложнение архитектуры за счет добавления ненужных абстракций.
- Причины: желание сделать код более гибким без необходимости.
- Пример: введение интерфейсов для простых операций, не требующих такой сложности.
Форма, нарушающая контракт (Leaky Abstraction)
Абстракция, которая не скрывает детали реализации.
- Причины: недостаточно продуманная архитектура, низкий уровень абстракции.
- Пример: библиотека, требующая знания о её внутренней структуре.
Необоснованные зависимости (Unnecessary Dependencies)
Модули зависят друг от друга без веской причины.
- Причины: плохое планирование, отсутствие модульности.
- Пример: логика бизнес-слоя зависит от UI-компонентов.
Перекрестные зависимости (Cyclic Dependencies)
Модули зависят друг от друга, создавая циклы.
- Причины: недостаточное планирование, отсутствие четкой архитектуры.
- Пример: мо дуль А зависит от модуля B, который зависит от модуля А.
Копипаст (Copy-and-Paste Programming)
Код копируется и вставляется без модификации или рефакторинга.
- Причины: спешка, отсутствие времени на рефакторинг.
- Пример: дублирование обработки ошибок в нескольких методах.
Черный ящик (Magic Numbers)
Использование в коде числовых значений без пояснения их смысла.
- Причины: недостаток времени на документирование, слабое проектирование.
- Пример: использование числа "7" для количества попыток без пояснений.