Сегодня мы вспомним один неназванный проект и поучимся на ошибках его реализации. Представьте себе огромный легаси-монолит где-то на 500к строк, и еще немного соседних мини-сервисов, который решают переписать с нуля. Уже кажется сомнительной идеей, но ладно, бюджеты не мои, решили так решили. Представьте теперь, что архитекторы и лиды решили пофаниться и пропушили вот такие решения:

🔹 Монолит решили распилить на N микросервисов. Микросервисы решают все проблемы, поэтому тут вопросов ноль. 🔹 Между микросервисами общаемся по GRPC, потому что он быстрый и его юзают в гугле. 🔹 Уменьшаем связанность кода, поэтому минимум расшаренных моделей, дублирование кода - наше всё. 🔹 Шарим экспертизу в команде, поэтому таски раскидываются рандомно и каждый разработчик понемногу кодит в каждый сервис. 🔹 Ну и еще немножко классных фундаментальных решений, но и так уже есть что обсудить, поэтому остановимся на этом.

Проект, естественно, надо было закончить в достаточно короткие для такого объема работ сроки. Его долго планировали, анализировали, проектировали, готовились, и вот пришло время, когда работяг пустили кодить, и вот что из этого вышло:

🔹 Очень быстро стало понятно, что со стадией анализа и проектирования произошел полный обсер, никто не понимает как всё должно работать, в каком порядке это всё кодить, ответственные поувольнялись, спрашивать некого, дока так себе, интеграцию продумывайте сами, ну и такое. Темп был галерный, таски горели практически всегда и поэтому нормально это сесть и продумать самому даже при всём желании не получалось. 🔹 Так как решили писать по сути с нуля и изначально не было ничего, так как объемы высираемого функционала были огромные, так как сборку и деплой на новый лад еще никто не настраивал, так как фронт там кодят тоже на коленке и вообще непонятно как, это всё по итогу практически не тестировалось. Ревью также практически не было, потому что все супер-заняты, кода прилетает просто миллион, ревьюить было просто некогда. 🔹 Микросервисная архитектура существовала ради разделения кода и усложнения жизни разработчикам. В каждом проекте была своя каша, практики не шарились, одно и то же в каждом сервисе каждый из разработчиков делал по-своему. Так как не было ответственных за каждый сервис, все кодили везде по чуть-чуть, весь этот пздец в коде был еще более заметен и усугублялся, потому что каждый привносил в каждый незрелый сервис что-то свое. Отчасти от того, что не успевал разбираться, отчасти потому что "ему казалось, что так лучше", отчасти потому что где-то не было экспертизы, ну и всё такое. 🔹 Так как надо было сохранить кучу старого функционала, а времени было мало, в новые сервисы он часто на скорую руку копипастился: без тестов, без каких-то сопутствующих фичей, которые в моменте было долго приделывать. По сути брали старый легаси код и просто убирали из него признаки легаси. 🔹 Так как связанность кода не поощрялась "архитекторами" и теми, кто это выдумывал, во взаимодействии между сервисами был минимум расшаренных моделей и всё это превратилось в то, что, например, модель заказа, которая пробрасывается от фронта через 3 сервиса до какого-то конечного сервиса, который этот заказ где-то там создает, должна была дублироваться примерно 20 раз: дто для апишки + модель в базе +  грпцшная и обычная модель для логики в каждом промежуточном сервисе + все эти модели надо было конвертить между собой, а там еще вложенные модели, которые тоже надо дублировать, уметь конвертить, записывать в базу, ну и всё вот это 🤡 Поэтому реализация любой таски выглядела так: откопипастить + пофиксить легаси, а потом кодить одну и ту же модель 20 раз. 🔹 От GRPC тоже не было никакого толку, потому что рпсы в проекте минимальные, а декларировать интерфейсы можно было бы чем-то и поудобней.

Судьба этого проекта останется загадкой, а в следующем посте мы подумаем, как можно было бы попробовать этого всего избежать.

А какие самые всратые проекты встречали на практике вы? 🤔