Gemeinsame wiederverwendete Elemente (Scriptlibraries, Teilmasken, Masken, Ansichten, Rahmengruppen etc.) entwickeln wir in einer zentralen Entwicklungs-Schablone.
Die Entwicklungs-Schablonen der einzelnen Anwendungen erben die Gestaltung der gemeinsamen Elemente aus der zentralen Schablone, die individuellen Elemente werden darin entwickelt.
In einem Freigabeprozess werden aus den Entwicklungs-Schablonen Produktiv-Schablonen erstellt, bei denen die Vererbung der gemeinsamen Elemente entfernt wurde (das geht auch mit Bordmitteln -> Wechseln der Schablone mit oder ohne Vererbung, einfach mal ausprobieren, eine Variante entfernt die Vererbung, vermutlich die MIT zukünftiger Vererbung der Gestaltung aus der Schablone).
Die Anwendungen erben Ihre Gestaltung komplett aus der Produktiv-Schablone. So kann kein Designtask die gemeinsamen Elemente in den produktiven Datenbanken austauschen.
Dieses Verfahren nutzen wir in unterschiedlichen Umfeldern erfolgreich seit wohl 15 Jahren. Und noch nie hat uns ein Designtask (der immer aktiv ist) eine Datenbank zerpflückt.
Einziger Haken dabei ist das eventuell notwendige Recompile. Alle Entwicklungs-Schablonen müssten recompiliert werden, wenn sich an den gemeinsamen Scripten die Strukturen ändern. Deshalb entwickeln wir nicht in Klassen, und wir ändern niemals Übergabeparameter für Subs oder Functions.