🌟Переписать нельзя оставить
Мы, программисты, стремимся к лучшему, поэтому обожаем всё переделывать. Особенно, когда за это неплохо платят. И в мире разработки программного обеспечения проекты периодически переписываются на новые технологии и подходы.
Лично мне приходилось участвовать в нескольких проектах, которые переписывались минимум по два раза! Чаще всего переписывался старый большой монолитный проект под так называемые “микросервисы” - это когда у вас вместо одного большого приложения, десятки мелких с отдельными базами данных. В свое время - такое переписывание было трендом, и не важно надо ли оно было действительно.
🥸На одном проекте я попал под самый разгар распила монолита. Процесс растянулся на 2 года. Бюджеты таяли, команда буксовала, инфраструктура трещала по швам. А простые фичи - те, что раньше делались за день - стали проходить через цепочку бюрократии и страданий неделями, а то и месяцами.
Обычно классический проект устроен как слоеный пирог: - доступ к данным - бизнес-логика - интерфейс для передачи данных пользователю или сторонней системе.
Чтобы переписать это на микросервисы «в лоб», нужно нанять DevOps-инженеров, развернуть сложную инфраструктуру и как-то распутать кучу связей в коде. На практике это реально дорого и долго.
💡Правда есть подход, который позволяет нескольно удешевить процесс, сохранив всем нервы. Называется он Vertical Slice Architecture (архитектура вертикальных срезов).
➡️Вот смотрите на примере кухни в ресторане: Там есть повар, ответственный за нарезку, повар по жарке и сборщик блюд. Посетитель заказал пиццу, и заказ идет через всех троих поваров. Если один заболел - кухня встала. Это классический «слоеный» монолит.
📎В качестве решения мы можем поделить кухню на автономные цеха. Представьте «Цех пиццы». Там работает повар, у которого свой нож, своя печь и свой запас ингредиентов. Он собирает заказ от начала и до конца, не ожидая, пока освободится «жарочный департамент» от бургеров. Такое вынесение ответственности за приготовление определенного продукта будем считать вертикальным срезом.
В коде же это означает, что мы берем одну конкретную фичу (например, «Регистрация пользователя») и грубо говоря кладем весь её код в одну папку. Там и логика, и работа с данными и какие-то интеграции.
Далее все проверяется и тестируется.
➡️В итоге: - разработчику достаточно удобно работать с текущей кодовой базов - открыл одну папку фичи и работаешь только в ней - бизнесу не нужно сразу покупать дорогую инфраструктуру и переписывать всё с нуля - мы сначала наводим порядок внутри текущего монолита - в случае, если фича больше не нужна - просто удаляем папку
🔥И самое главное: - если через полгода фичу действительно понадобится вынести в отдельный микросервис - просто берем готовую папку и «отрезаем» её за пару дней, а не месяцев.
Прежде чем строить «космический корабль» и тратить миллионы, может, стоит просто навести порядок?
Вертикальные срезы - это способ подготовить старую систему к тому, чтобы она была готова стать микросервисами в любой момент. Без переплаты, срыва сроков и потраченных нервов 🏆