Размышления о практиках хорошей архитектуры

Все практики хорошей архитектуры базируются на идее того, что требования будут меняться — и именно чтобы облегчить последующую поддержку — мы добавляем абстракции, паттерны, следуем SOLID-у и вот это вот все. Это, кстати, делает проектирование ПО очень сильно отличающимся от других видов разработки. Например, при проектировании моста никому в голову не придет на середине строительства превращать подвесной мост в разводной — а при разработке ПО считается, что проектировать надо так чтобы в любой момент любой слой можно было заменить безболезненно — переходя от реляционной БД к документно-ориентированной и обратно.

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

Представим себе молодого или не очень разработчика с несложной задачей — написать сервис который что-то получает по http, как-то элементарно меняет и отдает это в кафку (ETL-сервис). Если использовать высокоуровневые фреймворки — то код который все это выполняет уместится в 10 строк (не считая конфига). Но наш разработчик знает что должен быть слой контроллеров и слой сервисов. Далее, он задумывается — “что если завтра надо будет слать не в кафку в еще куда-то” — и делает абстрактный сендер с реализацией кафка сендер. А что если слать надо будет в разные топики — в зависимости от тела запроса? И он делает абстрактный тополоджиРесолвер с единственной реализацией — конкретным топиком. И, кстати, делает абстрактный бодиКонвертер — вдруг завтра поменяется формат передаваемых данных, абстрактный же мессаджКонвертр — вдруг завтра надо будет слать сообщения в другом формате.. Наконец. добавляет абстракцию фильтров, обработчиков ошибок отправки, обработчиков успешной отправки, слой репозитария (с пустой реализацией)… и гордо выставляет это на прод.
Проходит полгода — приходит молодой сотрудник которому он передает код. И молодой сотрудник видит семь абстрактных классов и две абстрактные фабрики — с пустыми реализациями. И у него возникает сложнопреодалимое желание запихнуть в жопу предшественнику всю банду четырех — вместе с Мартинами (Фаулером и Робином) в придачу.

Но возможна и другая ситуация — первый разработчик не заморачивается абстракциями — а фигачит все в контроллере — один метод на который мапится POST-запрос — в нем и преобразование данных и отправка в кафку. Но — проходит месяц и его просят добавить фильтр, слать не только в кафку но и писать в базу, при ошибке отправлять емэйл — в итоге он по чуть-чуть “дописывает” свой код — превращая его в макарону. Проходит пол года — он передает код другому сотруднику — тот видит макаронину кода и исполняется желанием запихнуть в жопу предшественнику всю банду четырех…

Есть еще вариант найти “почти готовое решение” для задачи — типа апач кэмела, спринг интегрешенала или кафкаконнекта — в которых “все работает из коробки” и задачку “переслать POST-запрос в кафку” можно сделать вообще без кода . Но пройдет пол года, сервис передадут другому человеку, его потребуется доработать — что потребует уже чуть более глубокое знание этих фреймворков — и поддерживающий будет думать — какого хрена здесь этот фреймворк вместо того чтобы самому написать 30 строк тривиального кода — разбирайся теперь с ним, да еще и обновляй до последней версии…
Я успел побывать во всех ролях — и передавал код-макаронину, и передавал равиоли-код с кучей абстракцией. И брал в поддержку код с безумным количеством слоев и брал в поддержку код с методами на 7000 строк делающими все что можно.

Очень редко но бывало и так что абстракция прям “подошла” когда для запуска сервиса с новыми требованиями хватило лишь добавить новую реализацию — но, увы, это редкость.
Вывод из этого только один — принять как должное, что предугадать в каком направлении будет меняться проект — практически не реально. И если “не угадали” — не испытывать комплекс самозванца. Относиться к “гибкой архитектуре” и “бест практикс” с уважением — но без фанатизма — не ленясь разбивать код по слоям и сервисам — но только тогда когда это действительно нужно — а не городя фасад абстрактных генераторов в трех строчках кода.