Software Architect · Модуль 23
Антипаттерны полезны не для обвинений. Они дают язык, чтобы раньше замечать системные ошибки мышления.
Cargo cult · ivory tower · distributed monolith · premature abstraction
Архитектурная ошибка часто выглядит умно в момент принятия и дорого через полгода.
Cargo cult копирует форму без причины
Надеть форму пилота не значит уметь посадить самолёт.
Cargo cult architecture появляется, когда команда копирует решения больших компаний без их контекста: микросервисы, service mesh, Kafka, Kubernetes, event sourcing, multi-region. Проблема не в инструментах, а в отсутствии собственной причины.
Профессиональная проверка простая: какое конкретное свойство мы покупаем и почему оно важно сейчас?
Ivory tower отрывает архитектуру от кода
Проектировщик, который никогда не был на стройке, рискует сделать красивый, но непригодный план.
Ivory tower architect создаёт диаграммы и стандарты, но не видит real constraints: legacy, tooling, developer experience, incidents, deadlines, team skills. В результате решения не внедряются или внедряются формально.
Архитектору не обязательно писать каждую строку, но он должен оставаться рядом с delivery: reviews, prototypes, migration, incidents, feedback от команды.
Антипаттерн можно исправлять только после того, как команда перестала считать его нормой.
Пример: остановить premature abstraction
Универсальный ключ, который открывает всё, часто плохо открывает конкретную дверь.
Команда хочет сделать generic workflow engine для трёх похожих approval flows. Архитектор предлагает сначала реализовать два потока явно, сравнить variability points и только потом выделять abstraction.
Это не отказ от архитектуры. Это защита от абстракции, которая появится раньше понимания домена.
Антипример: resume-driven development
Покупать инструмент ради витрины опасно: работать им придётся каждый день.
Инженеры выбирают технологию, потому что она выглядит хорошо в резюме или модна на конференциях. Не учитываются skill set команды, hiring market, maturity, tooling, operations и долгосрочная поддержка.
Архитектор должен уметь отделять технологический интерес от ценности для системы.
- Какие решения мы копируем без собственной причины? - Где диаграмма расходится с реальным кодом?
- Где абстракция появилась до третьего понятного кейса? - Какие технологии выбраны ради команды, а какие ради моды?