Микроархитекторы
Apr. 25th, 2022 01:14 am![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
dzzРазбирая код, который наворотил уволившийся сотрудник тогда ещё не моего отдела, не могу не заметить, что любителей применения микросервисной архитектуры в промышленной миддлвари нужно расстреливать ещё маленькими, ибо слепое увлечение этой технологией вредит неокрепшим умам.
Имеем приложение, осуществляющее, по сути, буферизацию и маршрутизацию запросов + опрос адресатов на тему статусов обработки этих запросов. Написано на python3 с asyncio.
Как это сделал бы нормальный архитектор: набор классов для представления данных в БД с методами ORM, интерфейс REST API для приёма запросов, корутина для отправки запросов и корутина для опроса статусов. Структурное построение программы - максимум три модуля + main.
Как это делает микросервисник: полная декомпозиция всего, что можно, отдельные классы на каждое мяу, развесистое дерево файлов, обработка каждого типа запросов отдельным модулем с тучей мелких взаимосвязанных функций. На выходе работающий, но абсолютно неремонтопригодный код.
В итоге, простое действие "добавим ещё один тип запросов и один тип объектов в БД" выливается в правку кода в 6 местах. В ШЕСТИ разных файлах, раскиданных по дереву. С обязательным прослеживанием и повторением всей логики обработки, разбитой на 100 маленьких медвежат, т.к. вносить в работающую схему костыльные решения, всё-таки, не хочется.
Вот сижу, тихо злюсь и пишу модификацию в таком вот грёбаном стиле. Радует только то, что на горизонте полугода смогу выкинуть этот компонент из системы совсем и сделать всё нормально.
Имеем приложение, осуществляющее, по сути, буферизацию и маршрутизацию запросов + опрос адресатов на тему статусов обработки этих запросов. Написано на python3 с asyncio.
Как это сделал бы нормальный архитектор: набор классов для представления данных в БД с методами ORM, интерфейс REST API для приёма запросов, корутина для отправки запросов и корутина для опроса статусов. Структурное построение программы - максимум три модуля + main.
Как это делает микросервисник: полная декомпозиция всего, что можно, отдельные классы на каждое мяу, развесистое дерево файлов, обработка каждого типа запросов отдельным модулем с тучей мелких взаимосвязанных функций. На выходе работающий, но абсолютно неремонтопригодный код.
В итоге, простое действие "добавим ещё один тип запросов и один тип объектов в БД" выливается в правку кода в 6 местах. В ШЕСТИ разных файлах, раскиданных по дереву. С обязательным прослеживанием и повторением всей логики обработки, разбитой на 100 маленьких медвежат, т.к. вносить в работающую схему костыльные решения, всё-таки, не хочется.
Вот сижу, тихо злюсь и пишу модификацию в таком вот грёбаном стиле. Радует только то, что на горизонте полугода смогу выкинуть этот компонент из системы совсем и сделать всё нормально.
