История изменений

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

а в чем проблема с точками расширения? В ООП программировании это часть архитектуры. Если структура изменятеся, надо думать над централизованным изменением архитектуры.

Наверное, можно разрешить какой-то манки-патчинг на уровне шаблонов. Если там XML - прикрутить XML трансформации. Для ООП всегда можно намутить какие-то трансформации тоже, в простейшем случае - миксины.

НО имхо это приведет к тоннам говнокода, когда никто не знает что и как работает, а может только запатчить чтобы не развалилось.

Имхо, работу архитектора никто кроме архитектора не сделает (на текущем уровне развития технологий, пока не изобрели ИИ)

А для поддержания архитектуры нужны:
- централизация (центализованное архитектурное видение, управление конфигурацией, четкое централизованное понимание командой «правильного способа делать вещи»)
- дисциплина
- отлаженные процессы («что делать, когда нам нужно добавить новый экстеншен поинт»)

И вот я думаю, что нужно обязательно как можно больше статических проверок со стороны компилятора, чтобы часть контроля за целостностью перенести с разработчика на автоматические тулзы

И автотесты желательно какие-то иметь, да (тесты по сути - еще один уровень полу-статической проверки над исходным языком)

Т.е. супер-технология лежит не в плоскости «движок шаблонов», а в области социальной, как так скоординировать команду, чтобы она писала в правильном ключе относительно общего архитектурного видения (возможно, применяя при этом разные технические трюки типа поддержания целостности через использование строго статического языка шаблонов или проверок автотестами)

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

а в чем проблема с точками расширения? В ООП программировании это часть архитектуры. Если структура изменятеся, надо думать над централизованным изменением архитектуры.

Наверное, можно разрешить какой-то манки-патчинг на уровне шаблонов. Если там XML - прикрутить XML трансформации. Для ООП всегда можно намутить какие-то трансформации тоже, в простейшем случае - миксины.

НО имхо это приведет к тоннам говнокода, когда никто не знает что и как работает, а может только запатчить чтобы не развалилось.

Имхо, работу архитектора никто кроме архитектора не сделает (на текущем уровне развития технологий, пока не изобрели ИИ)

А для поддержания архитектуры нужны:
- централизация (центализованное архитектурное видение, управление конфигурацией, четкое централизованное понимание командой «правильного способа делать вещи»)
- дисциплина
- отлаженные процессы («что делать, когда нам нужно добавить новый экстеншен поинт»)

И вот я думаю, что нужно обязательно как можно больше статических проверок со стороны компилятора, чтобы часть контроля за целостностью перенести с разработчика на автоматические тулзы

И автотесты желательно какие-то иметь, да (тесты по сути - еще один уровень полу-статической проверки над исходным языком)