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

Антипаттерн GOD Object Разными путями мы можем придти к тому, что в оном классе, модуле, сервисе собирается слишком много функционала, много данных и все остальные зависят от этого модуля или сервиса. Мы имеем страшную базу, big-models и много чего ещё в одном сервисе. При этом: - Крайне высокая степень связанности (coupling), при том не только на уровне межсервисного взаимодействия, но и внутри кода божественного сервиса. - Объект содержит несвязанные функции и данные, превращаясь в "свалку" логики. (Low-Cohesion) - Наличие BIG_моделей, в которую складываются все знания о мире в этой информационной системе по совсем не очевидной логике, - Как следствие - сложность тестирования и развития. Последние может выражаться даже в нереально низкой скорости погружения разработчиков в задачи. Как же так получилось? - Нарушение принципа единственной ответственности: Объект занимается множеством совершенно разных задач, что приводит к избыточной сложности. - Плохая архитектура: Когда проект не структурирован должным образом, и все компоненты сводятся к одному объекту, чтобы избежать создания дополнительных классов и связей между ними. - Отсутствие хорошего планирования: На начальных этапах разработки может не быть четкого представления о том, как будет распределяться ответственность между объектами, и это приводит к тому, что один объект растет и становится слишком сложным. - Низкий уровень инкапсуляции: Когда объект обрабатывает данные из разных частей системы, но не скрывает их детали, создавая зависимость между различными частями программы. - Технический долг: Часто GOD Object появляется из-за ускоренной разработки или избыточной экономии на архитектурных решениях, что со временем приводит к накоплению сложных и неуправляемых компонентов.

Антипаттерн "Отвлечение абстракции" (Abstraction Distraction). Этот антипаттерн про привязывания решения к внешней библиотеке или технологии. Когда библиотека, технология или решение использует и, в свою очередь, предлагает набор агрегатов, процессов или принципов реализации и вы, как архитектор или разработчик, ограниченны ими. Пример: Вы выбрали платформу low-code или базовую платформу для бизнес-приложений а-ля 1С, ЫФЗ? Axapta и так далее. Руководствовались принципами стабильности и экономии на рессурсов на разработку, ну например. При этом, вы получаете ровно тот набор высокоуровневых агрегатов, который вынуждены будете использовать до этапа выпиливания технологии из тех. стека компании. Та же история про шины или потоковые базы, а-ля kafka, вы вынуждены использовать атрибуты процесса работы с данными при проектировании системы. Что это значит для архитектора? Ограничения технического слоя архитектур(слой приложения) ы начинает просачиваться на прикладной слой, а может и выше.. Как этого избегать: 1. Универсальная рекомендация - не придумывайте решение до завершения этапа проектирования принципов прикладного слоя. 2. По Предметно-ориентированному проектированию, используйте защитный слой.

Анти-паттерн "Дизайн комитета" (Design By Committee) Объектно-ориентированные подходы проектирования систем принято разделять на два поколения, считается, что первое - проектирование на основе данных, второе - на основе паттернов проектирования. Касательно первого: считалось, что объекты — это сущности, которые можно потрогать. При этом получалось, что все члены команды не способны объять все агрегаты и понять общие принципы связей и взаимодействия между ними. Что приводило, в свою очередь, к появлению элитарной команды - комитета по проектированию. Так как команда, по умолчанию элитарна и её решениям необходимо верить. С другой стороны, команда элитарная в силу значимости принятых ею решений, что давало принадлежащим к ней сотрудникам ряд бенефитов, хотя бы даже в разрезе ЧСВ. Следовательно, сотрудникам команды должны активно участвовать в принятии решений и подтверждать свою полезность внесением предложений. Еще один аспект- это масштабность решений принятых комитетом и, часто, неопределенность сроков исполнения этих самых решений. В связи с этим, системы и артефакты архитектуры, вылетающие из под подобной структуры, характеризуются крайне высокой, не обоснованной сложностью. А еще, часто, непонятностью для остальной команды. Опосредованным следствием данной конструкции может быть появление уникальных компетенций в команде.

Анти-паттерн "Дымоходная система" (Stovepipe System) Часто так называют легаси-системы, при этом подразумевая безнадежность дальнейшего развития и вложений в неё. При этом, в общем случае, рефакторинг и обогащение функционалом такой системы, может привести к положительному эффекту, с точки зрения ТТМ и стоимости эксплуатации. Характеризуется общей неструктурностью архитектуры системы, как на уровне выбора технологий для каждого отдельного сервиса, так и интеграционных паттернов, выбора технологий и принципов разработки API. Как это выглядит в общем случае: первоначально был реализован или взят какой-то функционал и в дальнейшем обогащался новыми модулями или микро-сервисами. При этом, общих принципов разработки или хотя бы базовых принципов работы с архитектурой командой не фиксируется. И получается, что сервисы реализованы по разным технологиям, в одном сервисе могут сочетаться принципы реактивного и асинхронного программирования, внутри системы могут применяться разные языки, разные подходы к организации API и так далее. Кроме того, когда вижу подобные системы, обычно к этому присовокупляется еще и история с отсутствием внятной документации. Это ведет к высокой хрупкости в реализации системы, изменения в ней, могут привести к неработоспособности каких-либо её функций или вообще всей ИС. При этом, новые интеграции, интеграции внутри системы всегда сопровождаются болью, связанной с сложностью внесения изменений. Но, как писал в начале, рефакторинг рулит и не только кода, но и подходов. Подходов в первую очередь. Был у меня случай, когда в одном из моих мест работы, команда системы, которая приносила более 60 миллиардов в год, просто встала и ушла. И выяснилось, что вся документация была у них в Jira. более 65 микросервисов, написанные каждый как бог на душу положит, свой гео-прокси и так далее. Производство просто остановилось. Но за счет подхода к формализации задач и описанию системной архитектуры, с параллельным пересбором команды, позволило восстановить поставку за два месяца, а еще через два месяца повысить перформанс относительно старой команды в х3 раза. Такие дела.

Антипаттерн Cover your assets (Защити свои активы, ну или задницу) Ну или "Защити свою задницу", хотя все же это про активы. Все мы ищем свое место в жизни и вот решила одна организация, поняв, что живет не правильно, нанять корпоративного архитектора, технического архитектора, ИТ-лида, короче, любое тело, которое должно научить ИТ, департамент, отдел, подрядчика жить правильно. Проблема в том, что от архитектора ждут реального решения проблем, но реальное решение - это разработка однозначного решения, возложение на себя ответственности. А так же, скорее всего, сопровождение данного решения до его имплементации. То есть фактически, конечную пользу "архитектор" может принести только частично возложив на себя роль скиллового менеджера, так же проводя максимальное время с командой. Но ведь архитектор не про это, а про архитектуру - квадратики и стрелочки. Это проектирование и моделирование, а не пропихивание ногами своего решения, где только можно. И вот тут, отказ от возложения на себя ответственности начинает выражаться в витиеватости, сложности документов, неоднозначности описаний и всём том, что может привести к ответственности через однозначную интерпретацию документов архитектора. Вот и получается, что архитектура тратит калории и на процессы, которые не сильно-то нужны, а разработчики вынуждены вникать в отупляющие детали запутанных архитектурных артефактов. В конечном счете это все приводит к отделению архитектурных процессов от разработки. Архитекторы делают какую-то свою работу, а разработчики стараются идти своим путем, лишь бы поменьше с архитекторами общаться. Вот такие дела.

Антипаттерн Wolf ticket Антипаттерн «Волчий билет» – паттерн, при котором система или продукт разрабатывается с максимальным следованием стандартам и следует принципам открытости, при этом, команда, развивающая систему, при взаимодействии с другими командами в организации постоянно апеллирует к этим стандартам. При этом нужно помнить, что не более 10% стандартов разработки ПО имеют тесты – то есть, являются проверяемыми в конечном счете. При этом эти 10% относятся к стандартам языков программирования, но не к конечной методике разработки ПО. Стандарты, в данном случае, служат прежде всего инструментом узнаваемости бренда – повышения ЧСВ разработчиков и служат для аргументации правоты выбранных подходов в команде при построении диалога с соседями. По идеи стандарты должны служить для упрощения переносимости, миграции технологий, повышения стабильности. Но разность в их реализации сводят на нет данные преимущества. Так же, высокоуровневые архитектурные стандарты могут быть настолько сложны, что в общем случаи они имплементируются частично или в соответствии с уровнем понимания имплементирующей стороны. Резюмируя. Наличие Волчьего билета – это проблема для ландшафта и организации, ни разу не демонстрирующая уровень инженерной компетенции владельца билета.