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

найдите 10 отличий в вашем утверждении "здорово работает когда изменении элементов форм  существующих в обеих сравниваемых конфигурациях" и "Если элементы были добавлены и в одной конфигурации и в другой, то конфигуратор убьет одни из них"

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

точно, вспомнил. давно уже не пользовались сравнением, программное в основном.

С бодрым. А вот еще за архитектуру спрошу. Большое количество маленьких модулей как-то влияет на быстродействие решение? Хочу на одном проекте попробовать доработки выносить в модули с аналогичным названием с добавлением уникального префикса. Ожидаемые профиты: во-первых, поможем еще больше распараллелить работу программистов (у нас до сих пор связка хранилища и гита), во-вторых, возможно улучшит читаемость доработок. Имеет такая схема право на существование?

Или это слишком глубокая детализация и достаточно группировки доработок например по подсистемам и т.п.?

По ответственностям :)

Большое количество маленький модулей? Привет дублирование и велосипедостроение на каждый чих

На быстродействие вроде не влияет, а вот архитектура крайне стремительно превратится в наваристую такую тарелку спагетти

А текучка? :)

Почему? Просто доработки конкретного функционала будут производиться в соответствующем модуле с использованием других общих модулей.

А какой приемлемый уровень детализации? Подсистема?

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

Это вопрос решаемый на уровне анализа кода. Даже если программисты пишут в одном общем модуле - нет гарантии что они будут использовать функции друг друга, разве не так?

Ответственные за подсистемы? Ну возможно, если профилировать людей.
Правда это командную разработку убивает как концепцию

У нас нет ответственных за подсистемы :) выигрывает и проигрывает команда. Я просто пытаюсь понять насколько мелко резать модули и внедрить эту нарезку

Ну так там надо соглашениями обмениваться ещё на уровне проектирования, если уж идёт параллельная командная разработка

А, модули обычно по подсистемам нарезаются, да. Как некоторый юнит бизнес логики

Хорошо, спасибо за идею, подумаю.

Ну идея то в целом в бсп реализована, там так все и нарезано.) Есть подсистема есть программный интерфейс в апи, ну и всякие детали технической реализации типа справочники/регистры и т.д. но это все должно волновать только разработчика подсистемы.