Функциональная декомпозиция
Это когда разделение на классы делается не по функциональному уровню, а по частям бизнес-процесса, что в итоге даёт очень дегенеративную архитектуру.
Это когда тащат бэк на фронт и наоборот: фронт запихивают куда-то внутрь классов бэка. Это когда запрос остатков внезапно открывает соединение с каким-то веб-сервисом, это когда в функции сложения двух чисел строится красивый отчёт для оператора, и так далее.
Симптомы
- Классы называются по шагам бизнес-процесса, а не по своей роли.
- Слои (UI, логика, данные) перемешаны.
- Крошечные «процедурные» методы вместо осмысленных объектов.
- Побочные эффекты (сеть, отчёты, база) разбросаны по коду.
Пример
Вот простой пример функциональной декомпозиции. Выяснять плюсы и минусы ООП тут не планируем — это лишь простая демонстрация усложнения понимания в процедурном решении.
Процедурная версия расчёта кредита для клиента — «плохой» вариант:
Объектно-ориентированная версия расчёта кредита для клиента — «хороший» вариант:
Почему возникает
Распутывание такого кода, когда он на всём проекте, — отличное приключение. Обычно такая практика случается, когда на проекте — несколько джунов, и нет никого, кто выступил бы архитектором. Или когда разработчики быстро клепают MVP, понимая, что завтра этот код полетит в корзину, а в итоге он используется годами. Иногда я вижу такое в коде аутсорс-компаний, которые берегут время разработчиков.
Как исправить
- Разделять код по слоям и ответственности, а не по шагам процесса.
- Выносить побочные эффекты (сеть, хранилище) за пределы бизнес-логики.
- Начинать с определения доменных объектов и их поведения.
Итог в том, что если систему построить так, провести рефакторинг практически нельзя. Приходится с этим жить и постепенно делать из этого блоб.