Code für Datenreplikation (ETL) bauen, der Werte nicht still verändert und keine Daten preisgibt

## Ohne Auftrag weder pushen noch Migrationen ändern Richte jede Änderung auf das zu lösende Problem aus. Bevorzuge die kleinste in sich schlüssige Änderung, sofern keine umfassendere Umstrukturierung erforderlich ist, um die Korrektheit zu bewahren. Bevor du ein Muster, eine Abhängigkeit, eine Hilfsfunktion oder eine Testvorrichtung einführst, prüfe den benachbarten Code und halte dich an die geltenden Konventionen des Arbeitsbereichs. Behandle die Konfiguration der Formatierung, die Diagnosen des Übersetzers und die Einstellungen der statischen Prüfung im Arbeitsbereich als maßgebliche Quelle für durchsetzbare Stilregeln. Nimm keine Schreibvorgänge im Versionsarchiv vor, veröffentliche keine Zweige, eröffne keine Änderungsanträge und schreibe den Versionsverlauf nicht um, sofern der Benutzer diese Handlung nicht ausdrücklich verlangt. Ändere keine Datenbankmigrationen, sofern die angeforderte Arbeit nicht ausdrücklich eine Migrationsänderung erfordert. Dies schließt Kommentare und nicht ausführbaren Text in Migrationsdateien ein. Führe aufwendige Prüfungen des gesamten Arbeitsbereichs nur aus, wenn ihr Umfang gerechtfertigt ist. Nutze für risikoarme Änderungen an Dokumentation oder Konfiguration die kleinste relevante Prüfung und berichte genau, was ausgeführt wurde. ## Module nach Datenkonzepten ordnen und APIs zuerst privat halten Gliedere nach Domänenkonzepten statt nach allgemeinen Sammelkategorien. Halte das Replikationsverhalten und replikationsspezifische Typen zusammen; platziere wiederverwendbare Datenbankgrundbausteine, Hilfsfunktionen für Quellen und Replikationsplätze sowie den Zugriff auf Metadaten an einer Integrationsgrenze. Nutze Paketgrenzen nur, wenn ein anderes Paket tatsächlich von der Programmierschnittstelle abhängt. Bevorzuge innerhalb einer Domäne Module mit Namen wie `schema`, `data`, `event`, `store`, `source` oder `slots`. Beschränke ausführbare Programme der obersten Ebene auf die Ablaufsteuerung. Verschiebe Einzelheiten der Umsetzung in klar abgegrenzte Hilfsfunktionen und Module. Verwende standardmäßig private Sichtbarkeit und erweitere sie nur für einen tatsächlichen Aufrufer. Bevorzuge zuerst private, dann paketweite und zuletzt öffentliche Sichtbarkeit. Behandle jeden erneuten Export als Vertrag einer Programmierschnittstelle: - vermeide Platzhalterexporte aus internen Modulen; - stelle nur die kleinste nützliche Einrichtungsoberfläche bereit; - halte die Steuerung von Arbeitseinheiten, Kodierer und Dekodierer, Laufzeitverbindungen sowie Einzelheiten der Umsetzung privat; - vermeide Kompatibilitätsfassaden, sofern sie nicht als stabile Programmierschnittstelle beabsichtigt sind. Bevorzuge klaren, üblichen Code gegenüber raffinierten Abstraktionen. Ordne Typen, Konstruktoren, öffentliche Methoden und private Hilfsfunktionen in einer gut lesbaren Reihenfolge an. ## Rundung und andere stille Wertänderungen abfangen Prüfe Werte an Ort und Stelle, wenn das Ziel andernfalls eine unbemerkte Bedeutungsänderung akzeptieren würde, etwa Rundung, Abschneiden, Begrenzung, Typumwandlung, Überlauf oder Genauigkeitsverlust. Wenn das Ziel einen nicht unterstützten Wert bereits mit einem ausdrücklichen Fehler ablehnt, verdopple aufwendige Prüfungen im Schreibpfad nicht ohne nachgewiesenen Bedarf. Nutze geprüfte oder Trait-basierte numerische Konvertierungen, wenn sie verlustfrei und verfügbar sind. Nutze bewusst verlustbehaftete Typumwandlungen nur, wenn der Verlust verstanden ist, der Wertebereich gegebenenfalls geprüft wurde und die Zieldarstellung sie erfordert. Nutze eine implizite Konvertierung nur, wenn die Zuordnung nicht fehlschlagen kann, semantisch verlustfrei und werterhaltend sowie offensichtlich ist. Bilde Teilaktualisierungen mit drei unterschiedlichen Zuständen ab: - ausgelassene Felder bewahren den gespeicherten Wert; - ein ausdrücklicher Nullwert löscht einen optionalen Wert oder setzt einen vorbelegten Wert zurück; - Werte, die keine Nullwerte sind, ersetzen den gespeicherten Wert. Nutze bei der Umwandlung einer vollständigen Konfiguration in die Semantik einer Teilaktualisierung eine ausdrückliche Konvertierungshilfe. Verbirg einen Wechsel vom Bewahren zum Löschen nicht hinter einem generischen Konvertierungs-Trait. ## Bei kaputten Eingaben klare Fehler statt Abstürze liefern Nutze typisierte Fehler und Ergebniswerte für behebbare Fehlschläge. Ergänze eigene Kontextangaben wie Vorgänge, Kennungen, Anzahlen, Typen oder Anweisungen und bewahre dabei den ursprünglichen Fehler als Ursachenkette. Reduziere einen zugrunde liegenden Fehler nicht auf eine Zeichenkette, es sei denn, eine bewusst bereinigte Meldung ist für den Aufrufer sicherer. Antworten öffentlicher Programmierschnittstellen dürfen keine Fehler von Datenbanktreibern, internen Abfragen, Kundendaten oder Einzelheiten der Infrastruktur offenlegen. Behalte Programmabbrüche verletzten Invarianten der Programmierung vor. Externe Eingaben, fehlerhafte Syntax, nicht unterstützte Werte und Fehler des Systemzustands müssen ausdrückliche Fehler zurückgeben. Parser-Einstiegspunkte müssen leere Eingaben, ein unerwartetes Eingabeende, fehlerhafte Maskierungen, ungültige Bytefolgen, ungültige Wertebereiche, Überlauf, Unterlauf und nicht unterstützte Syntax ohne Programmabbruch behandeln. Bevorzuge geprüfte Zugriffe, Iteratoren und die Analyse von Byteabschnitten, wenn die Eingabe die Versatzwerte bestimmt. Direkte Indizierung ist nur zulässig, wenn eine lokale Grenze oder eine Invariante exakt großer Abschnitte dies offenkundig sicher macht. Ergänze Rückfalltests für jede Grenze fehlerhafter Eingaben, die zuvor einen Programmabbruch oder eine unbemerkte Fehlinterpretation verursachen konnte. ## Je nach gehaltenem Zustand wählen, wie Hintergrund-Tasks beendet werden Vermeide als unsafe gekennzeichneten Code, sofern er nicht notwendig ist. Jeder als unsafe gekennzeichnete Block muss unmittelbar eine Sicherheitserklärung enthalten, die die Invariante nennt, durch welche der Vorgang korrekt ist. Bevorzuge Besitz und Ausleihe gegenüber unnötigem Kopieren oder innerer Veränderlichkeit. Kapsle lang laufende asynchrone Arbeit in benannten Aufgaben oder Hilfsfunktionen und wähle das Beendigungsverhalten anhand des verwalteten Zustands: - das Freigeben eines Aufgabenverweises entkoppelt die Aufgabe; brich verzichtbare Hintergrundarbeit ausdrücklich ab, wenn sie sofort enden soll; - das Freigeben einer Aufgabengruppe bricht jede von ihr verwaltete Aufgabe ab; - brich eine Aufgabengruppe nicht unnötigerweise unmittelbar vor dem Verlassen des Gültigkeitsbereichs ab, durch dessen Ende sie ohnehin freigegeben wird; - nutze ausdrückliche Abbruchvorgänge, wenn die Aufgabengruppe bestehen bleibt, ihre Aufgaben jedoch enden müssen; - nutze geordnete Signalisierung und warte auf die Beendigung, wenn Aufgaben Transaktionen, gepufferte Schreibvorgänge am Ziel oder einen wiederholungsabhängigen Replikationszustand verwalten. Füge keine aufwendige Abstimmung der Beendigung für Abfrage- oder Telemetrieaufgaben hinzu, deren Zustand gefahrlos verworfen werden kann. ## Geheimnisse und Kundendaten aus Code und Logs heraushalten Behandle nachverfolgte Dateien, Zweige, versionierte Änderungen, Prüfberichte, Protokolle, Bildschirmaufnahmen, Testvorrichtungen, erzeugte Artefakte und Terminalausgaben als potenziell öffentlich. Lege niemals Zugangsdaten, Zugriffsschlüssel, private Endpunkte, Kundendaten, Nutzdaten aus dem Produktivbetrieb, personenbezogene Daten oder geschützte Konfigurationen in Code, Tests, Dokumentation, Beispielen, Kommentaren, Nachrichten, Telemetrie, Einzelheiten von Programmabbrüchen oder erzeugten Dateien ab. Nutze erfundene Platzhalter in Beispielen. Speichere echte Geheimnisse ausschließlich in freigegebenen Umgebungsvariablen, ignorierten lokalen Dateien, Geheimnisverwaltungen oder dem Geheimnisspeicher der kontinuierlichen Integration. Wenn ein verdächtiger Wert echt wirkt oder aus einer privaten Umgebung stammt, gib ihn nicht wieder. Halte den Veröffentlichungsweg an, melde den Ort ohne den Wert zu zitieren und empfehle den Austausch oder Widerruf, wenn eine Offenlegung stattgefunden haben könnte. Für die Beobachtbarkeit gilt: - bevorzuge Kennzeichnungen mit geringer Anzahl möglicher Werte; - protokolliere strukturelle Metadaten wie Tabellen- und Spaltennamen, Typen, Anzahlen, Längen, Positionen und Vorgangsnamen; - protokolliere niemals Zeilenwerte, Zellinhalte, vertrauliche Anfrage- oder Antwortinhalte, Zugangsdaten oder Zugriffsschlüssel; - nutze sichere Anzeigeformatierung für Fehler und strukturierte Felder; - bereinige die Inhaltserfassung für vertrauliche Routen und Überwachungsbereiche. ## Echte Replikationsereignisse testen und prüfen, ob Tests wirklich liefen Führe zuerst die engsten relevanten Tests aus und erweitere sie anschließend, wenn gemeinsames Verhalten, Rückfälle oder die Anfrage dies rechtfertigen. Prüfe, ob die erwarteten Tests tatsächlich ausgeführt wurden; ein erfolgreich beendeter Befehl ohne passende Tests ist keine bestandene Verifizierung. Liste Tests auf, bevor du unsichere Filter anwendest. Führe Dokumentationstests getrennt aus, wenn das Hauptsystem zur Testausführung sie nicht unterstützt. Verwende vorhandene Testvorrichtungen, Datenbankhilfen, Warteprimitive und Zusicherungen erneut, bevor du eine eigene Testinfrastruktur erstellst. Für ereignisgesteuerte Integrationstests: 1. Registriere Benachrichtigungen oder Wartesignale, bevor der Erzeuger das Ereignis ausgeben kann. 2. Führe Schreibvorgänge auf der Quellseite aus. 3. Warte auf die erwarteten Benachrichtigungen. 4. Beende die Verarbeitungskette und warte auf ihren Abschluss, bevor du den Zielzustand prüfst, sofern der Test nicht ausdrücklich das Verhalten während der laufenden Verarbeitung abdeckt. 5. Prüfe den kumulierten Ereignisverlauf, sofern nicht ein Neustart oder eine isolierte Phase dessen Löschung erfordert. Stimme erwartete Ereignisse der Änderungsdatenerfassung auf das tatsächliche Verhalten der Replikatidentität der Quelldatenbank ab. Erwarte in Betriebsarten, die sie nicht ausgeben können, keine Zeilen mit unvollständigen Aktualisierungen. ## Code dokumentieren und ausgeführte Prüfungen melden Dokumentiere öffentliche und private Elemente in knapper, präziser Sprache. Verknüpfe Typen und Methoden über die unterstützten Verweise des Dokumentationssystems. Setze in Kommentaren Satzzeichen und platziere sie oberhalb des Codes, den sie erläutern. Definiere Namen von Messwerten und Schlüssel von Kennzeichnungen als Konstanten, zentralisiere gemeinsame Kennzeichnungen und registriere Beschreibungen einmalig. Behalte eine klar abgegrenzte Messwertaufgabe je Quelle sowie eine kleine Oberfläche zur Ablaufsteuerung bei. Bestätige vor dem Abschluss den betroffenen Umfang: - das geänderte Ziel lässt sich übersetzen; - die Formatierung ist fehlerfrei; - die statische Analyse ist mit der Prüfkonfiguration des Arbeitsbereichs fehlerfrei; - relevante Modul- und Integrationstests sind bestanden und wurden tatsächlich ausgeführt; - Dokumentationstests sind bestanden, sofern sie anwendbar sind; - Kommentare und Dokumentation entsprechen dem endgültigen Verhalten; - Messwerte, Protokolle und Kennzeichnungen entsprechen den Benennungs- und Datensicherheitsregeln. Berichte die durchgeführten Prüfungen, ihren Umfang und alle bewusst ausgelassenen Prüfungen. Behaupte nicht allein aufgrund des Rückgabestatus eines Befehls, die Arbeit sei abgeschlossen, wenn seine Ausgabe zeigt, dass kein bedeutsames Ziel geprüft wurde.