Комментарии 5
Код считается устаревшим (легаси) как только его разработчик покидает компанию. А может быть и раньше.
Поэтому иногда часто стараются создать **ально огороженный загончик для чужого кода. Который можно не рефакторить и даже не читать, а полностью переписать следующим автором исходя лишь из контракта API, обычно простого.
Всё.
Есть ещё иные очень слабые доводы but it depends
Код становится легаси тогда, когда непонятно, как он работает. Бывает что это происходит сразу после того, как код написан, бывает в результате многократных изменений.
У такого кода нет тестов, или они плохие.
Если есть нормальные тесты, то можно посмотреть тест кейсы и понять, как оно должно работать. Тесты показывают, как нужно пользоваться компонентом.
И можно менять код, не боясь его сломать, потому что тесты покажут, если что-то перестанет соответствовать требованиям.
Разницу между монолитами и микросервисами уже объяснил, ввиду третью переменную. «Есть ли вариант, приближенный к микросервисам, но более доступный? Есть!». Это мини-сервисы – упрощённая версия микросервисов, где приложение делится на несколько крупных частей.
Обычно, если вы уже делите, то все проблемы "деления" уже позади и вы умеете в "деление". На много или мало - зависит от того, что вы хотите получить.
Второй момент - это во что уже умеет команда. Если там это условно 5й проект - какая проблема? Все все знают и делают с закрытими глазами. Если ваша команда не умеет - ну, можно либо учить, либо добавить людей, которые уже умеют. Лучше конечно добавить
Третий момент - как по мне, основные преимущества микросервисов лежат в упрощении процесса разработки разных фич в паралельном режиме. Понятно, это все можно делать в разных вариантах, но все таки задача собрать приложение в варианте 5 старых сервисов + 3 обновленных, а потом 6 + 2, но уже под другую фичу делается несоклько проще
Но монолит — это когда один повар схватил ротовирус, и вот они вчетвером сидят на горшке пятисотят 🥹🥹🥹🥹 За компанию, так сказать
Микросервисы нужны только когда чётко определены зоны ответственности сервисов и вылет одного сервиса не утянет за собой остальные, и когда количество групп разработчиков примерно равно количеству микросервисов с бизнес-логикой. Ну и когда есть чёткое понимание сколькими фичами типа транзакций в базе придётся пожертвовать.
А если на 3 разработчиков 25 сервисов которые на каждый запрос пользователя устраивают пинг-понг по сети и на отвале 20-какого-то запроса в базе остаётся невалидный стейт - кажется что лучше бы было использовать монолит
«Почему вам не нужны микросервисы для старта нового проекта»