Eine mehrsprachige Datenbibliothek ändern, ohne Dateiformate und öffentliche Schnittstellen zu brechen

## Den nativen Kern und die schlanken Sprachanbindungen kennenlernen Betrachte das Repository als einen nativen Kern mit schlanken Anbindungen für andere Sprachen. Der Kern verantwortet das Verhalten des Datenformats, Kodierung, Komprimierung, Dateien, Indizes, Ein- und Ausgabe, Objektspeicher, lineare Algebra, Tabellenoperationen, optionale Fachbereiche, Testinfrastruktur und Entwicklerwerkzeuge. Die Anbindungen stellen dieses Verhalten bereit, ohne Validierung oder Geschäftslogik zu duplizieren. Bewahre die wichtigsten Architekturmerkmale: asynchrone Ein- und Ausgabe, nativen spaltenorientierten Speicher, versionierte Schreibvorgänge mit Manifestverfolgung, arbeitslastorientierte Kodierungen und eine gemeinsame Speicherabstraktion für lokale und entfernte Objektspeicher. Lies die Repository-Anleitung und die Anleitung für jede betroffene Sprache oder jedes betroffene Verzeichnis, bevor du Befehle oder Codeänderungen planst. Verzeichnisspezifische Regeln präzisieren den Repository-Vertrag, statt ihn zu ersetzen. ## Stabile Formate kompatibel halten, instabile frei ändern Behandle jedes als stabil ausgewiesene Format als dauerhaften Kompatibilitätsvertrag. Eine Änderung an stabilen Daten muss sowohl Rückwärtskompatibilität als auch Vorwärtskompatibilität bewahren. Behandle jedes als instabil ausgewiesene Format als verwerfbar. Es darf sich frei ändern; füge für Dateien aus früheren instabilen Überarbeitungsständen weder Kompatibilitätscode noch Migrationen, Ausweichlösungen oder Tests hinzu. Bewerte neue Kompatibilitätsarbeit anhand der neuesten veröffentlichten stabilen Version und halte weiterhin jeden Vertrag für stabile Formate ein. Zustände, die nur im aktuellen Entwicklungszweig vorhanden sind, stellen keine Kompatibilitätsbedingungen dar. Schwäche einen klareren oder vollständigeren Entwurf nicht allein deshalb ab, um einen unveröffentlichten Zwischenstand zu erhalten. ## Dokumentierte Befehle und Erstellungsprofile nutzen statt einer anderen Werkzeugkette Ermittle vor der Ausführung die dokumentierten Befehle für Prüfung, Tests, statische Analyse, Formatierung, Abdeckung, Leistungsmessung und Integration der betroffenen Sprache. Verwende die vom Repository bereitgestellten Paket- und Testauswahlen, statt einen parallelen Arbeitsablauf zu erfinden. Wechsle nicht zu einer anderen Umgebungsverwaltung oder Werkzeugkette, nur weil ein Befehl zu fehlen scheint, langsam ist oder nicht verfügbar wirkt. Wenn ein sprachspezifischer Befehl außerhalb des dokumentierten Arbeitsablaufs fehlschlägt, berichtige zuerst die Umgebungsnutzung und führe den vorgeschriebenen Befehl erneut aus. Erst danach darfst du feststellen, dass eine Abhängigkeit oder ein Werkzeug nicht verfügbar ist. Verwende die im Repository festgelegten Kompilierungsprofile statt behelfsmäßiger Überschreibungen der Optimierung. Führe Leistungsmessungen und Leistungsanalysen mit einer optimierten Erstellung durch, die Debugsymbole behält. Deaktiviere die Optimierung zur Linkzeit nur für lokale Fehlersuche, durch Ein- und Ausgabe begrenzte Leistungsmessungen oder Untersuchungen der Kompilierungszeit, bei denen sie den gemessenen Engpass nicht beeinflussen kann. Starte für Integrationsprüfungen nur die erforderlichen Prüfdienste, setze die dokumentierten Umgebungswerte und führe das vorgesehene Integrationsziel aus. ## Fokussierten Code schreiben, der Daten streamt, statt sie im Speicher zu sammeln Verwende Englisch in Code, Beispielen und Kommentaren. Code soll sowohl auf Lesbarkeit als auch auf Ausführung ausgerichtet sein. Füge Kommentare nur hinzu, wenn sie einen nicht offensichtlichen Grund erklären, und entferne direkte Debugausgaben vor der Begutachtung zugunsten des etablierten Ablaufverfolgungs- oder Protokollierungssystems. Lagere Logik, die an zwei oder mehr Stellen wiederholt wird, in eine gemeinsame Hilfsfunktion aus. Belasse nur einmal verwendete Logik an ihrer Aufrufstelle. Führe eine Hilfsfunktion nur ein, wenn sie die geistige Belastung wesentlich senkt oder erhebliche Doppelungen beseitigt; füge keine dünne Hülle hinzu, die einen Aufruf nur umbenennt oder weiterleitet. Halte Änderungen zielgerichtet. Vermeide beiläufige Umstrukturierungen, Neuformatierungen und rein optische Änderungen. Bewahre das Datenstromverhalten, statt Stapel im Arbeitsspeicher zu sammeln, und bevorzuge für die Zugehörigkeitsprüfung dichter Ganzzahlen kompakte Bitmap-Strukturen gegenüber allgemeinen Hashmengen. ## Sprachanbindungen schlank halten und alte öffentliche Schnittstellen als veraltet markieren, statt sie zu brechen Zentralisiere Validierung und Logik im nativen Kern und halte jede Sprachanbindung als schlanke Hülle. Verwende in allen Anbindungen dieselben Parameternamen; benenne sie überall oder nirgends um. Brich niemals eine vorhandene öffentliche Signatur an Ort und Stelle. Kennzeichne die alte Methode mit der von der Sprache unterstützten Anmerkung als veraltet und füge eine neue Methode hinzu. Ersetze Gruppen sich gegenseitig ausschließender boolescher Schalter durch einen einzigen Aufzählungs- oder Modusparameter. Aktualisiere bei geändertem Kernverhalten jede zutreffende Anbindung, erzeugte Schnittstelle, jedes Beispiel und jede Kompatibilitätsprüfung gemeinsam. Eine Anbindung darf einen Wert, den der Kern ablehnt, nicht stillschweigend anders auslegen. ## Werte nach ihrem Inhalt benennen und ungültige Eingaben mit klaren Fehlern ablehnen Benenne eine Variable danach, was ihr Wert ist, und nicht danach, wie er zufällig verwendet wird. Lass überflüssige Präfixe weg, wenn der umgebende Typ oder das Modul den Fachbereich bereits erkennen lässt. Verwende in Programmierschnittstellen und Dokumentation einheitlich eine freigegebene Pluralform und bevorzuge speicherneutrale Namen gegenüber anbieterspezifischen Begriffen. Aktualisiere beim Umbenennen eines Typs, einer Struktur oder einer Aufzählung zugleich Methoden, Felder, Variablen, Tests und Dokumentation. Validiere Eingaben an den Grenzen der Programmierschnittstelle und lehne ungültige Werte mit aussagekräftigen Fehlermeldungen ab. Begrenze oder verändere sie niemals stillschweigend. Lehne sich gegenseitig ausschließende Erzeugungs- oder Einrichtungsoptionen ab, wenn beide vorhanden sind. Nimm relevante Variablennamen, Werte, Größen und Typen in Fehlermeldungen auf. ## Wenige Abhängigkeiten hinzufügen und Sperrdateien synchron halten Bevorzuge die Standardbibliothek oder vorhandene Arbeitsbereichsabhängigkeiten, bevor du ein externes Paket hinzufügst. Halte Änderungen an Sperrdateien beabsichtigt, nimm sachfremde Aktualisierungen zurück und fixiere eine fehlerhafte Abhängigkeit nur mit einem Kommentar, der auf den vorgelagerten Vorgang verweist. Aktualisiere bei einer Änderung der Arbeitsbereichsabhängigkeiten die Stammsperrdatei und jede Sperrdatei einer ausgeschlossenen Anbindung über die dokumentierten manifestspezifischen Prüfungen und committe anschließend alle entsprechenden Änderungen. Halte den Offline-Hook zur Lockfile-Synchronisierung aktiv. Lege optionale oder fachspezifische Abhängigkeiten hinter Funktionsschaltern. Bevorzuge für umfangreiche Fachfunktionalität ein eigenes Paket, damit Standarderstellungen und Nutzende keinen unnötigen Code übernehmen. ## Zu jeder Fehlerbehebung und jeder neuen Funktion einen Test schreiben Jede Fehlerkorrektur und jede Funktion benötigt zugehörige Tests. Akzeptiere keinen Code ohne Tests. Verwende die parametrisierte Testfunktion der Sprache, wenn sich Fälle nur in ihren Eingaben unterscheiden, und gib den Fällen lesbare Namen. Ersetze Ausgaben in Tests durch Zusicherungen, weil Ausgaben allein keine Rückfälle erkennen. Erweitere einen vorhandenen Test, wenn er das Verhalten bereits abdeckt, statt eine überlappende Testdatei hinzuzufügen. Lege Ergänzungen am etablierten Testort ab. Ein übersprungener Test muss auf einen Nachverfolgungsvorgang verweisen; füge niemals eine bloße Übersprunganmerkung ohne dauerhaften Grund hinzu. ## Mit leeren und Null-Daten sowie alten stabilen Dateien testen Nimm für Lesevorgänge, Indizes und Suchläufe Szenarien mit mehreren Fragmenten auf. Decke in Indextests Null-Elemente, vollständig aus Null-Elementen bestehende Sammlungen, leere Sammlungen und Null-Spalten ab. Tests für Vektorindizes müssen einen Recall-Wert von mindestens 0,5 bestätigen und dürfen nicht nur prüfen, ob die Indexerstellung erfolgreich war. Verwende für die Rückwärtskompatibilität versionsverwaltete Datensätze, die von älteren stabilen Versionen erzeugt wurden. Halte ein Datenerzeugungsskript vor, das die Erzeugerversion bestätigt, und kopiere diese Prüfdaten vor dem Lesen in einen temporären Speicher. Deaktiviere Dokumentationstests nicht nur, um die Kompilierung zu vermeiden. Schreibe Beispiele, die innerhalb eines funktionsförmigen Zusammenhangs kompilieren. Schließe reine Testhilfen mit der freigegebenen Abdeckungsanmerkung des Projekts von der Abdeckung aus, statt die Abdeckungsgrenzen für Produktionscode zu schwächen. ## Jede öffentliche Schnittstelle mit einem kompilierbaren Beispiel dokumentieren Dokumentiere jede öffentliche Programmierschnittstelle und füge ein Beispiel hinzu. Verweise auf die betreffenden Typen und Methoden und halte Beispiele bei jeder Umstrukturierung des Codes mit den tatsächlichen Signaturen im Einklang. Verwende ASCII-Baumdiagramme für hierarchische Strukturen wie Kodierungsebenen, Dateiformate und Speicheranordnungen. Befolge die Einrückungsregeln des Dokumentationssystems, einschließlich einer Einrückung um vier Leerzeichen unter Hinweisdirektiven. Lies Kommentare und Dokumentation vor der Begutachtung auf Tippfehler gegen. Dokumentation, die nicht mehr kompiliert oder eine veraltete Programmierschnittstelle nennt, ist ein Kompatibilitätsfehler und kein optisches Problem. ## Issues mit Labels versehen und vor dem Änderungsantrag die Lint-Prüfungen bestehen Übergib beim Erstellen eines Vorgangs über ein Befehlszeilenwerkzeug oder eine Programmierschnittstelle ausdrücklich die Kennzeichnung für Fehler-, Funktions- oder Leistungsarbeit, da die Vorlagenautomatisierung umgangen werden kann. Stelle dem Titel die passende Einordnung voran, damit inhaltsbasierte Automatisierung ein zuverlässiges Ersatzsignal erhält. Verwende die üblichen Präfixe des Repositorys für Änderungstitel und ergänze bei Bedarf einen Geltungsbereich. Führe vor dem Erstellen oder Aktualisieren eines Änderungsantrags die vorgeschriebenen statischen Prüfungen für jede berührte Sprachoberfläche aus, auch wenn sie aufwendig sind. Befolge für die statischen Prüfungen jeder Sprache den Umgebungsablauf ihrer Anleitung. Wenn eine vorgeschriebene Prüfung nicht ausgeführt werden kann, benenne das Hindernis ausdrücklich in der Zusammenfassung des Änderungsantrags, statt eine abgeschlossene Validierung anzudeuten. ## Reviews auf schwere Fehler und Sicherheitsprobleme konzentrieren Die Aufmerksamkeit von Beitragenden und Wartenden ist begrenzt. Halte Begutachtungen knapp und klar und konzentriere dich auf Fehler mit höchster Schwere, Leistungseinbußen und Sicherheitsbedenken. Wiederhole weder ausführliche Änderungen noch bereits richtige Punkte. Prüfe einheitliche Benennung, etablierte Fehlerbehandlungsmuster und Testabdeckung. Nenne die betroffene Stelle und erläutere die konkrete Folge jeder blockierenden Feststellung.