у меня конечно сразу вопрос - что это принципиально меняет)
но сейчас на мой взгляд это уже обоюдное решение)

у меня конечно сразу вопрос - что это принципиально меняет)
но сейчас на мой взгляд это уже обоюдное решение)

Хм... Эти 6 историй несовсем связаны с текущими реалиями. Да и вообще с реальностью.
Я работал не в большом количестве мест, но ситуация везде одна и та же — монолит, мотивация, взять всё и переписать
Но увы, жизнь, а точнее работа, научила меня что оно так не работает. Рефакторинг монолита — вещь почти не достижимая, если не гугл, майкрософт или что-то большое, известное и с деньгами.
Если цель быстрее доставлять фичи, то как она связана с рефакторингом? В хороший код проще вносить изменения, а значит и выходить они будут быстрее? Да?
Увы, но нет. Даже если у вас будет идельный с точки зрения дядушки Боба код, то усилия по подержанию его в таком состоянии при внесении изменений могут очень  дорогими. А если нужно бежать вперёд роняя кирпичи, чтобы успевать за рынком?
На моей прошлой работе в каждой команде есть свой монолит, или один монолит на 2 команды. И есть стремление сделать мега архитектуру на микросервисах.  Процесс шёл 2 года (пока я там работал) и идёт до сих пор. А монолиты как приносили компании основной доход, так и приносят. А всю эту новомодную инфраструктуру пытаются удержать на плечах команда DevOps, у которых уже колени трясутся.
Новенькие приходят, ругаются, но когда понимают как работает бизнес начинают молча есть кактус. Так как он в деньги конвертируется. И правилом бойскаута пользуются. Ну и да, потихоньку выделяют независимые части в микросервисы.
Такие дела

Если существующий продукт  в текущем состоянии приносит деньги или если фаундеры и стейкхолдеры  осознают,  что  им даст переписывание  - все вполне приземляется на "текущие" реалии

Более радикальное решение,чем рефакторинг, но кейсы реальные, продукты успешные,  так что может даст  команде и ПМу, как минимум, пространство для размышлений  и  идей:

https://habr.com/ru/post/441456/

мне кажется что это очень частый кейс, чаще всего любой бизнес стратует с монолита, который со временем обрастает "мясом и жиром"
со временем приходит понимание, что пора его делить на части, дабы облегчить себе жизнь и работу
и начинается :)

Прям сейчас пилим монолит на части и поэтапно поднимаем новую платформу на микросервисной архитектуре. Да не просто. Но уже есть плоды и оно того однозначно стоит. Ну и конечно же без поддержки и понимания бизнеса это было бы не возможно.

Прям сейчас пилим монолит на части и поэтапно поднимаем новую платформу на микросервисной архитектуре. Да не просто. Но уже есть плоды и оно того однозначно стоит. Ну и конечно же без поддержки и понимания бизнеса это было бы не возможно.

Был у меня однажды ооочень большой легаси. В какой-то момент любые изменения стали дорогими и тяжёлыми. С помощью подсчетов, собранных примеров, мрачных прогнозов и красивых презентаций удалось получить бюджет на рефакторинг. А дальше из огромного монолита аккуратно выпиливали кусочки и впиливали новое решение. Это очень долго, технически сложно, но зато без остановки сервиса и все такое. В итоге, после замены корной части боль снизилась и бюджеты тоже, в итоге процесс растянулся на многие годы.
Из полученного опыта:
- без обоюдного желания команды и бизнеса прям никак. Видел примеры без обоюдного - было больно и грустно. Бабло все же побеждает зло.
- еще нужны сформулированные цели, зачем это все. Предприятие рискованное, сложное, если цели нет, может получиться рефакторинг ради рефакторинга. Поэтому имеет смысл относиться к этому, как к бизнесовой задаче, считать ROI (хотя бы попытаться)
- взять и переписать с нуля большой и сложный продукт - почти не видел успешных случаев (как правило тестов нет, требования утеряны, такой кучи денег нет). Хотя нет, один был: достаточно денег, очень заинтересованный бизнес и крутая инженерная команда. Но там я только рядом стоял, наверняка были подводные камни.
- Аккуратное распиливание монолита, дублирование функций работает, но это дорого и долго. Если продукт большой, то это может быть очень дорого и очень долго, поэтому нужны п1 и п2