


Einem modularen Netzwerkdienst Module hinzufügen, ohne die Modulgrenzen zu verletzen
Hilft, wenn eine KI einen modularen Netzwerkdienst ändert oder erweitert. Sie verbindet Module nur über gemeinsame Schnittstellen, baut und testet mit den Werkzeugen des Repositorys, gibt für Clients sichere Fehler zurück und teilt keinen Zustand zwischen Anfragen.
Diese KI-Regeln verwenden
## Module über gemeinsame Schnittstellen verbinden, nicht über interne Details
- Das Modulsystem als zentrale Erweiterungsgrenze behandeln. Authentifizierung, Speicherung, Validierung, Umwandlung, Weiterleitung und Protokollendpunkte sollen gemeinsame Rahmenwerkschnittstellen implementieren, statt einander über interne Implementierungsdetails aufzurufen.
- Stabile Schnittstellen, Konfigurationsgrundbausteine, Adressverarbeitung, Fehlertypen und Protokollierungsverträge gehören in eine wiederverwendbare Rahmenwerksebene. Konkrete Implementierungen gehören in interne, nach Rollen gegliederte Pakete.
- Den Programmeinstieg schlank halten. Er soll das Dienstpaket laden, die Registrierung der eingebauten Module sicherstellen und die Startfolge aufrufen.
- Übergeordnete Module über die Konfiguration und ein verzögert initialisiertes Register verbinden. Jede Anfrage oder Nachricht durch eine ausdrückliche Verarbeitungskette aus Prüfern, Modifikatoren und anhand von Abgleichregeln ausgewählten Zielmodulen leiten.
- Kreisabhängigkeiten vermeiden, indem Implementierungen von stabilen Schnittstellen und nicht von gleichgeordneten Implementierungen abhängen.
## Mit dem Build-Wrapper des Repositorys bauen und betroffene Tests ausführen
- Das Erstellungs-Hilfsprogramm des Projektarchivs einschließlich der unterstützten Kompilierungskennzeichen und Funktionsoptionen als verbindlichen Erstellungspfad verwenden. Es nicht durch einen behelfsmäßigen Compilerbefehl ersetzen, der Versionsangaben oder erforderliche Schalter auslässt.
- Bei bereichsübergreifenden Änderungen die vollständige Einheitstestsuite ausführen. Wenn ein Verhalten Protokoll-, Speicher- oder Auslieferungsgrenzen überschreitet, die Integrationstestumgebung aus ihrem dokumentierten Arbeitsverzeichnis ausführen.
- Die vom Erstellungssystem vorgenommene Einbettung der Versionsangabe beibehalten. Wenn die Laufzeitumgebung eine auf nativen Komponenten beruhende Abhängigkeit verwendet, vor der Quelltextdiagnose prüfen, ob der erforderliche native Compiler und die erforderlichen Bibliotheken verfügbar sind.
- Während der schrittweisen Bearbeitung einen gezielten Pakettest bevorzugen und vor Abschluss den direkt betroffenen Integrationspfad ausführen. Jeden ausgelassenen Test zusammen mit dem konkreten Umgebungsgrund melden.
## Ein neues Modul im Ordner seiner Rolle anlegen und registrieren
1. Die Implementierung im internen Verzeichnis ihrer Rolle ablegen, etwa für Validierung, Zielverarbeitung, Authentifizierung, Speicherung, Nachschlagen, Umwandlung oder Endpunktverarbeitung.
2. Sowohl die gemeinsame Modullebenszyklus-Schnittstelle als auch die rollenspezifische Schnittstelle implementieren. Rollenverträge in der stabilen Rahmenwerksebene halten.
3. Die Erzeugungsfunktion während der Paketinitialisierung nach der festgelegten Benennungskonvention mit Rollenpräfix registrieren.
4. Die Implementierung über die vom Projektarchiv vorgesehene Registrierungsimportanweisung oder das Manifest in die Verkettung der eingebauten Dienstmodule aufnehmen. Wenn das festgelegte Muster die Registrierung durch einen Nebeneffekt bewirkt, muss der Registrierungscode ausschließlich diesem Nebeneffekt dienen.
5. Wenn vorhanden, von einem bestehenden Rollengerüst oder Hilfsbaustein ausgehen. Den zustandslosen Hilfsbaustein nur verwenden, wenn das Modul tatsächlich keinen anforderungsübergreifenden veränderlichen Zustand hält.
6. Gezielte Tests für Konfiguration, Registrierung, Erfolgsverhalten, vorübergehende Fehler und die Zuordnung von Grenzfehlern ergänzen.
## Fehler zurückgeben, die eine mögliche Wiederholung anzeigen und interne Details verbergen
- Für Fehler, die Modulgrenzen überschreiten, das strukturierte Fehlerpaket des Rahmenwerks verwenden. Keinen unklassifizierten formatierten Fehler zurückgeben, wenn der Aufrufer Protokollstatus, Wiederholungsverhalten oder Modulzuordnung benötigt.
- Den externen Statuscode, falls unterstützt den erweiterten Status oder Untertyp, eine allgemeine klientensichere Meldung sowie den Namen der zuständigen Prüfung oder des Ziels angeben.
- Vorübergehende Fehlschläge ausdrücklich kennzeichnen, damit Verteiler Bedingungen für einen erneuten Versuch von dauerhaften Zurückweisungen unterscheiden können.
- Klientenseitig sichtbare Meldungen von Serverkonfiguration, internen Pfaden, Zugangsdaten und Implementierungsdetails freihalten.
- Unerwarteten internen Fehlschlägen strukturierte Diagnosefelder hinzufügen und sie über den Rahmenwerkprotokollierer erfassen. Die ursprüngliche Ursache bewahren, ohne sie entfernten Klienten offenzulegen.
## Keinen Zustand zwischen Anfragen teilen und panics in Hintergrundaufgaben abfangen
- Veränderlichen Zustand einer einzelnen Anfrage niemals zwischen Anfragen oder Nachrichten teilen. Davon ausgehen, dass Prüfungen und Umwandlungen nebenläufig ausgeführt werden, sofern der Rahmenwerksvertrag sie nicht ausdrücklich serialisiert.
- Jede gestartete goroutine und jede Hintergrundaufgabe muss an ihrer Grenze einen panic abfangen, den Fehler erfassen und verhindern, dass eine einzelne Aufgabe den gesamten Dienst zum Absturz bringt.
- Externe Kennungen vor dem Vergleich oder der Speicherung normalisieren. Bei domänenähnlichen Kennungen die vom Rahmenwerk verlangte Unicode-Darstellung, Normalisierungsform und Unicode-Fallfaltung anwenden, statt eine eigene örtliche Bereinigung zu erfinden.
- Die Modulkonfiguration über die gemeinsame Konfigurationsabbildung und Lebenszyklusmethode auswerten. Unbekannte oder ungültige Einstellungen einheitlich mit den bestehenden Modulen zurückweisen.
- Den Rahmenwerkprotokollierer anstelle des globalen Protokollierungswerkzeugs der Programmiersprache verwenden. Wenn das Rahmenwerk sie bereitstellt, vorgangs- oder auslieferungsbezogene Protokollierer erstellen, damit zusammengehörige Ereignisse ihren Kontext behalten.
- Vor dem Zusammenführen Registrierung, Konfigurationsauswertung, nebenläufige Ausführung, Normalisierung, strukturierte Fehlschläge und Protokolle durch Tests an der jeweils engsten Grenze prüfen, die das Verhalten nachweist.
