нуууу, не всегда. иногда это обоснованно, рефакторинг, улучшение. А иногда просто легаси код не хотят курить

ну и правильно))

если легче переписать чем разбираться в старом, почему бы не переписать?

Я бы начал с разговора с разработчиками. Если они не умеют или не хотят продумывать архитектуру в начале процесса разработки, то это нужно исправлять. Это увеличивает их работу, увеличивает работу ручных тестировщиков и автоматизаторов.

Я с трудом представляю проект, в котором один и тот же функционал меняется каждые 2 недели (не знаю как часто у вас он меняется, я просто сделал предположение). Выглядит такое очень странно.

Мы в команде сделали веб-сервис, который мониторит ключевые изменения в репозиториях и выдаёт сухую выжимку по ним. Если там что-то критичное, то идём и теребим разработчиков, пытаясь выяснить зачем они это сделали и кому это понадобилось. Это позволяет следить за изменением кода, пока ещё не закончился цикл разработки. Плюс, не даёт разработчикам творить что-то безнаказанно и подобные случаи уменьшаются.

ооо, а веб сервис не опенсорсный?

Нет, к сожалению. Мы не сможем это выложить публично.

Меняется часть функционла, которая влияет на общий функционал. Пресдтавте объект данных, очень огромый, который может меняться в зависимости от того, что нащёлках пользователь, на разных страницах, в разные периоды времени. И этот главный объект изпользуется для всего фукнционала как источник информации для актуализации данных на фронте. (ещё и реал тайм) вот это мой случай)

за спринт может быть несколько интеграций, рефакторин + расширие какого то функциона) и каждый из них может сломать или изменить главный объект)

Да, я понял проблему. Пока идей дополнительных нет. Сложно что-то сказать, не видя продукт. :(

Хороший наброс. :)

с чего это?

Ну, общая идея звучит так:
Вы (команда) можете снизить себе количество боли двумя способами:
1 - Избавляться от god object, распиливая его на куски.
Тогда эффект от изменений локальных кусков будет меньше.
2 - Делать все изменения в нем обратно совместимыми с предыдущими версиями.

Но это требует:
- Определённых договорённостей внутри команды.
- Определенного количества времени, на это затрачиваемого.

Если вам (как члену команды) кажется, что это стоит того - соберите аргументы и статистику по тому, сколько проблем это генерирует и идите продавать идею техлиду и команде.

Спасибо за совет) обдумаю)

Ну, потому что:
1. Не легче.
2. Выйдет, скорее всего, хуже.
3. Разбираться в существующем все равно придётся.

это категоричное мнение?)

думаю вы не очень хорошо разбираетесь в вопросе.

Или вы. :)

да уж) про поддерживаемость кода на досуге почитайте)

все же просто так "вдруг" решают свои сервисы переписать)))

Я бы, конечно, предложил аргументы использовать, но если такой стиль дискуссии больше нра, то советую почитать "Рефакторинг" Мартина Фаулера на досуге.
Там довольно много про то, как правильно "переписывать" сервисы. :)