Wiederverwenden vor Neuerfinden
Unternehmenssoftware entsteht innerhalb einer größeren Umgebung. Identitäts- und Zugriffsverwaltung, Protokollierung, gemeinsame Integrationen, Designsysteme, freigegebene Abhängigkeiten und Sicherheitspraktiken existieren bereits. Dürfte jeder Coding-Agent diese unabhängig auswählen oder neu erstellen, entstünden uneinheitliche Anwendungen und wachsender Wartungsaufwand.
Das SHAPE Framework geht deshalb von unternehmensweit freigegebenen Bausteinen und Mustern aus. Ein Projekt sollte diese Fähigkeiten nutzen, soweit sie die Anforderungen erfüllen, und vor einer wesentlich neuen Abhängigkeit oder Architekturentscheidung eine Freigabe einholen.
Freigegebene Plattformen und Muster
Ein Unternehmen kann mehrere freigegebene Anwendungsstacks statt einer einzigen universellen Technologiewahl unterstützen. Beispielsweise kann es unterschiedliche freigegebene Ansätze für Browseranwendungen, mobile Anwendungen, ERP-Erweiterungen und Integrationsdienste pflegen. Jeder Ansatz kann eigene Start-Repositories, Bibliotheken, Authentifizierungsmuster, Komponenten und agentenlesbare Anleitungen haben.
Ein Projekt wählt unter Berücksichtigung seiner Bedürfnisse und Einschränkungen den passenden Stack aus diesen freigegebenen Optionen. Der Coding-Agent soll innerhalb dieser Wahl implementieren, statt aus Bequemlichkeit ein anderes Ökosystem einzuführen. Passt keine freigegebene Option zu einer echten Anforderung, bewerten der Architekt und die zuständigen Unternehmensverantwortlichen die Ausnahme gemäß bestehender Richtlinie.
Das SHAPE Framework schreibt weder eine bestimmte Programmiersprache noch ein Webframework, einen Hostinganbieter, eine Datenbank oder ein Integrationsprodukt vor. Diese Entscheidungen gehören zu den technischen Unternehmensstandards und zur dokumentierten Projektarchitektur.
Bibliotheken und gemeinsame Fähigkeiten
Gemeinsame Bibliotheken und Dienste können Authentifizierung, Autorisierung, Validierung, Protokollierung, Beobachtbarkeit, Fehlerbehandlung und weitere wiederkehrende Anforderungen abdecken. Ihre Dokumentation sollte korrekte Nutzung, bekannte Einschränkungen und unterstützte Erweiterungspunkte erklären. Wiederverwendung hilft Spezialisten, eine kleinere Sammlung vertrauter Lösungen zu prüfen.
Designsysteme und Komponenten
Freigegebene UI-Komponenten und Gestaltungsregeln ermöglichen Agenten, einheitliche Anwendungen zusammenzusetzen, ohne für jeden Bildschirm einen neuen Button, ein neues Formularverhalten oder eine neue visuelle Konvention zu erfinden. Eine neue Komponente oder Variante sollte einen tatsächlichen Bedarf erfüllen und der Governance für gemeinsame Bausteine folgen.
Lokale und gemeinsame Änderungen
Nicht jede nützliche projektspezifische Komponente sollte zum Unternehmensstandard werden. Der Architekt sollte bewerten, ob ein Kandidat wiederverwendbar, verständlich, wartbar, sicher und mit bestehenden Bausteinen vereinbar ist. Gemeinsame Übernahme braucht bewusste Betreuung; zufällige Projektentscheidungen überallhin zu kopieren ist keine Wiederverwendung.
Für Agenten lesbare Anleitung
Eine freigegebene Komponente oder ein Dienst ist für Coding-Agenten nützlicher, wenn knappe Anweisungen, Beispiele und Einschränkungen vorliegen. Die Organisation kann die Agentenleistung verbessern, indem ihre tatsächlichen Standards verständlich und leicht auffindbar sind. Diese Anweisungen ergänzen technische Zugriffsbeschränkungen, ersetzen sie jedoch nicht.
Kontinuierliche Verbesserung
Projekterfahrung kann fehlende Komponenten, schwache Anweisungen oder wiederkehrende Reibung aufzeigen. Kurze Retrospektiven zwischen Product Engineer und Architekt identifizieren Verbesserungen, die lokal bewahrt oder als gemeinsame Bausteine vorgeschlagen werden sollten. So können Unternehmensmaterialien vollständiger werden, ohne zu einem starren Regelkatalog für jeden denkbaren Fall zu werden.