Антипаттерны программирования, которые все знают и все равно используют

Антипаттерн — это решение, которое выглядит разумным в моменте, но системно ухудшает код. Знать их по названию и замечать в собственном проекте — два разных навыка. Второй приходит только через практику: код-ревью, архитектурные разборы, опыт поддержки legacy.

Спроси любого разработчика про God Object — объяснит. Про Spaghetti Code — скривится и кивнет. Про Cargo Cult — улыбнется с узнаванием. И все равно они появляются в продакшене. В новых проектах, в «быстром» рефакторинге, в коде, который писали «временно, до следующего спринта».

Дело не в незнании. Дело в давлении дедлайнов, командных привычках и в том, что антипаттерн проектирования почти никогда не выглядит как ошибка в момент принятия решения.

Разберем семь самых живучих — с симптомами, реальными последствиями и конкретными путями выхода.

Что такое антипаттерн и чем он отличается от просто плохого кода

Термин появился в 1995 году в работе Эндрю Кенига как антагонист паттернам проектирования из книги «Банды четырех». Антипаттерн — это не просто небрежный код. Это повторяющееся решение, у которого есть название, задокументированные симптомы и известные последствия.

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

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

1. God Object — класс, который знает все

God Object (он же «Blob», он же «Всезнающий объект») — это класс, который постепенно берет на себя ответственность за все подряд: хранит состояние, управляет бизнес-логикой, ходит в базу, формирует ответы API. На старте он был маленьким и разумным.

Потом пришел дедлайн. Добавить метод сюда быстрее, чем создавать новый класс. Еще один. Еще. Через полгода UserService содержит 3 000 строк, 47 методов и зависит от двенадцати других объектов.

Почему это проблема

• Тестировать God Object почти невозможно — слишком много зависимостей
• Любое изменение затрагивает непредсказуемые части системы
• Параллельная работа двух разработчиков в одном файле — постоянный источник конфликтов при слиянии

Практический признак: если вы не можете объяснить назначение класса одним предложением без союза «и» — скорее всего, перед вами God Object. Принцип единственной ответственности (SRP из SOLID) существует именно против этого.

Как выходить

1. Выпишите все обязанности класса в список
2. Сгруппируйте по смыслу — это будущие классы
3. Рефакторьте постепенно, покрывая тестами каждый шаг
4. Не переписывайте все сразу — это заканчивается новым God Object

2. Spaghetti Code — когда структура растворяется

Спагетти-код — это когда логика переплетена настолько, что следить за потоком выполнения физически сложно. Условия внутри условий, функции, вызывающие друг друга по кругу, глобальные переменные, которые меняются «где-то там».

Это не всегда результат халтуры. Чаще — следствие роста без плана: код писался под одну задачу, потом под другую, потом третью. Без архитектурного слоя каждое расширение добавляло новый виток.

Реальная стоимость

По данным исследования CAST Research (2012), поддержка плохо структурированного кода обходится в среднем в 3,61 доллара за строку кода в год — против 0,79 доллара для кода с понятной архитектурой. Разница в четыре раза.

• Новый разработчик тратит недели, чтобы понять логику
• Исправление одного бага создает два новых
• Покрытие тестами становится почти невозможным

Выход — не «переписать все с нуля» (это почти никогда не работает), а постепенный рефакторинг: выделение функций, введение слоев, замена глобального состояния на явные зависимости.

3. Copy-Paste Programming — размноженные ошибки

По оценкам SonarSource (2023), дублированный код составляет от 10 до 30% кодовой базы в типичных enterprise-проектах. Механика простая: нашел похожий блок, скопировал, чуть поправил. Работает? Коммит.

Проблема обнаружится позже — когда в исходном блоке найдут баг. Его исправят. Но пять копий останутся сломанными, и никто не вспомнит, что они существуют.

Принцип DRY (Don't Repeat Yourself) — не про красоту кода. Это про предсказуемость: каждый кусок логики живет ровно в одном месте, и его изменение гарантированно затрагивает всех, кто его использует.

Инструменты — SonarQube, CodeClimate, встроенные детекторы дублирования в IDE — находят Copy-Paste автоматически. Подключить их к CI/CD занимает час. Убедить команду реагировать на результаты — сложнее.

4. Magic Numbers — числа, которые никто не понимает

В коде появляется строка вроде:

if (seconds > 86400) { expireSession(); }

86400 — секунд в сутках. Очевидно? Только если вы сами писали этот код. Следующий разработчик потратит несколько минут на поиск, откуда взялось это число.

Magic Numbers появляются там, где автор знал контекст и не счел нужным его зафиксировать. Нормально в черновике. Катастрофично в продакшне — особенно если число потом меняется в одном месте из трех.

Решение — три шага, 30 секунд

1. Замените число именованной константой: SECONDS_PER_DAY = 86400
2. Добавьте комментарий с источником, если значение неочевидно
3. Конфигурационные значения — в env или конфиг-файл, не в код

5. Cargo Cult Programming — ритуалы вместо понимания

Термин пришел из антропологии. После Второй мировой жители тихоокеанских островов видели, как военные самолеты привозят товары. Когда военные ушли, островитяне строили деревянные взлетные полосы и соломенные наушники — воспроизводя ритуал без понимания причинно-следственной связи.

В разработке это выглядит так: разработчик видит паттерн в чужом проекте, в статье, на Stack Overflow — копирует, потому что «так делают все», не разобравшись, решает ли это его задачу.

Типичные примеры антипаттерна

• Микросервисы для проекта из трех разработчиков, где монолит справился бы лучше
• Kubernetes для приложения с нагрузкой 50 запросов в сутки
• Брокер сообщений там, где хватило бы прямого вызова функции

Вопрос до внедрения любого паттерна: «Какую конкретно проблему это решает в нашем случае?» Если ответ размытый — это сигнал остановиться.

6. Golden Hammer — когда у вас молоток, все выглядит как гвоздь

Команда хорошо знает React — значит, административная панель тоже будет на React. Привычно работать с PostgreSQL — значит, туда же пойдут данные для кэша, сессий и очередей.

Golden Hammer отличается от Cargo Cult тем, что здесь есть реальная экспертиза — просто примененная не к той задаче. Проблема не в инструменте, а в отказе оценивать альтернативы.

Последствия

• Производительность ниже: инструмент работает, но не оптимально
• Приходится «обходить» ограничения там, где они не предусмотрены
• Поддерживаются возможности, которые просто не нужны для задачи

Практика Architecture Decision Records (ADR) помогает: перед выбором технологии фиксировать рассмотренные альтернативы и причины выбора. Это делает решение осознанным, а не автоматическим.

7. Lava Flow — окаменевший код в продакшне

Lava Flow — мертвый или устаревший код, который остался в кодовой базе, потому что никто не решается его удалить. Как лава: вытекла, застыла, стала частью рельефа.

Источники разные: прототипы, которые случайно попали в продакшн; экспериментальный код «пока оставим»; зависимости от удаленных фич, которые не убрали; закомментированный код-«кладбище».

Почему не удаляют

• «Вдруг это все-таки где-то используется»
• «Автор ушел из компании, кто знает, зачем он это написал»
• «Нет тестов, страшно что-то трогать»

Страх обоснован, но проблему не решает. Мертвый код путает новых разработчиков, иногда вызывается случайно и затрудняет рефакторинг живых частей.

Решение: включить поиск мертвого кода в регулярный процесс. Инструменты — Deadcode (Go), Vulture (Python), ts-prune (TypeScript), встроенные анализаторы IDE. Удалять небольшими итерациями с версионированием — откатить всегда можно.

Почему антипаттерн проектирования продолжают применять, зная о нем

Честный ответ неудобный.

Во-первых, давление дедлайнов. Технический долг — это кредит. Иногда брать его разумно: быстро выйти на рынок важнее чистой архитектуры на старте. Проблема начинается, когда долг не возвращают.

Во-вторых, коллективное решение. «Все пишут вот так» — мощный аргумент в команде. Изменить устоявшуюся практику труднее, чем следовать ей.

В-третьих, знание без применения. Знать про God Object и замечать его в собственном коде прямо сейчас — разные навыки. Второй требует практики и обратной связи: код-ревью, парного программирования, архитектурных разборов.

Наконец, контекст. Copy-Paste в прототипе на три дня — это не то же самое, что Copy-Paste в платежном сервисе. Не все антипаттерны одинаково вредны в любой ситуации.

Частые вопросы по теме

1. Чем антипаттерн отличается от code smell?

Code smell — более широкое понятие: любой признак, что с кодом что-то не так. Антипаттерн — конкретное повторяющееся решение с названием, задокументированными симптомами и известными последствиями. Каждый антипаттерн — это code smell, но не наоборот.

2. Можно ли использовать антипаттерн намеренно?

Да, если понимаете последствия. Дублирование в тестах иногда оправдано — тест должен быть понятен без чтения соседнего кода. Magic Number допустим, если контекст очевиден и значение не будет меняться. Главное — осознанный выбор, а не случайность.

3. С чего начать, если кодовая база уже полна антипаттернов?

Не пытаться исправить все сразу. Выбрать один антипаттерн, который создает наибольшие проблемы прямо сейчас. Покрыть тестами затронутый код. Рефакторить маленькими шагами, фиксируя договоренности в ADR — чтобы история решений не терялась.

4. Как не допускать антипаттернов в новом коде?

• Код-ревью с явным чек-листом по антипаттернам
• Линтеры и статический анализ в CI/CD
• Архитектурные сессии перед крупными фичами
• Культура «остановиться и спросить» вместо «быстро склепать»