Ändere eine Datenbank-Speicher-Engine, ohne Geschwindigkeit oder Kompatibilität zu verlieren

## Schreibe lesbaren Code, der Fehler und Nebenläufigkeit korrekt behandelt Schreibe klaren, selbsterklärenden Code mit aussagekräftigen Namen und Kommentaren für nicht offensichtliche Invarianten. Bevorzuge gut lesbaren Steuerfluss gegenüber raffinierten Tricks, die nur einen geringfügigen Geschwindigkeitsgewinn bieten. Befolge das Formatierungswerkzeug, die Benennungsregeln und die Strukturmuster des Repositoriums. Verwende durchgängig den üblichen Status- oder Fehlertyp des Projekts. Gib Fehler mit genügend Zusammenhang weiter, damit sich der fehlgeschlagene Vorgang bestimmen lässt. Verwirf niemals stillschweigend einen Fehler oder einen ungeprüften Statuswert. Vermeide Zusicherungen bei behebbaren Fehlern in Produktionspfaden. Decke ungültige Eingaben, Ressourcenerschöpfung, E/A-Fehler, Beschädigung und teilweise Fortschritte ab. Bewahre Datenbanksemantik wie Schlüsselsortierung, Sichtbarkeit von Schnappschüssen, Dauerhaftigkeit und Wiederherstellungsverhalten. Dokumentiere Synchronisierungsannahmen unmittelbar bei den Daten, die sie schützen. Prüfe Sperren, atomare Operationen, Speicherreihenfolge, Wettlaufrisiken und Verklemmungsrisiken gemeinsam. Halte die Ressourcenbereinigung in Erfolgs-, Fehler-, Abbruch- und Abschaltpfaden ausdrücklich fest. Richte Kommentare auf lokale Verträge statt auf die gegenwärtige Begründung eines bestimmten Aufrufers aus. Führe wiederholte Logik zusammen, wenn eine gemeinsame Abstraktion eine stabile und in sich schlüssige Verantwortung besitzt. Kennzeichne eine korrektheitskritische Änderung erst dann als zusammenführungsbereit, wenn Fehlerpfade und Nebenläufigkeitsverhalten getestet sind. ## Optimiere Code nach Ausführungshäufigkeit und belege es mit Benchmarks Behandle Leistungsbewusstsein als Anforderung an die Arbeit an Speicher-Engines. Stelle die Korrektheit vor Feinstoptimierungen sicher und wähle zugleich von Anfang an zweckmäßige Algorithmen und Datenstrukturen. Ordne den betroffenen Code nach Ausführungshäufigkeit ein: - In häufig ausgeführten Pfaden vervielfachen sich jede Zuweisung, Kopie, Verzweigung und jedes Zwischenspeicherverfehlen über zahlreiche Vorgänge. - Mäßig häufig ausgeführte Pfade erfordern einen gemessenen Ausgleich zwischen Klarheit und Geschwindigkeit. - Selten ausgeführte Pfade bevorzugen Wartbarkeit, sofern die Laufzeitanalyse keine wesentlichen Kosten zeigt. Belege Leistungsbehauptungen mit Vergleichsmessungen und Daten aus Laufzeitanalysen. Vergleiche mit einem geeigneten Ausgangswert und berichte Arbeitslast, Konfiguration und Streuung. Verringere bei hinreichender Begründung dynamische Zuweisungen in häufig ausgeführten Pfaden durch Wiederverwendung, Vorabzuweisung, Speicherbereiche oder Speicherpools. Bevorzuge Verschiebevorgänge, Sichten, Verweise und Bearbeitung am Ursprungsort gegenüber unnötigen Kopien. Ordne Daten und Zugriffsmuster für gute Lokalität an und vermeide falsche gemeinsame Nutzung. Ziehe unveränderliche Arbeit aus Schleifen heraus, fasse wiederholte Vorgänge zusammen und verringere schwer vorhersagbare Verzweigungen. Nutze Hinweise zur Verzweigungswahrscheinlichkeit nur für wirklich seltene oder kostspielige Fälle, nicht für verbreitete Konfigurationen. Ermögliche die Vektorisierung durch den Übersetzer mittels geeigneter Datenanordnung, bevor du ausdrückliche systemnahe Befehlsfunktionen einsetzt. Verwende ausdrückliches SIMD nur dort, wo es unterstützt, gemessen und wartbar ist. Setze RAII und klare Besitzverhältnisse ein, um Lecks bei geringem Zusatzaufwand zu verhindern. Behalte keine komplexe Optimierung ohne reproduzierbaren Nutzen bei. ## Entwirf kompatible APIs mit Optionen für nur einen Zweck Belasse übergeordnete Richtlinien beim Aufrufer oder in der Richtlinienschicht. Stelle aus tieferen Schichten präzise, wiederverwendbare Mechanismen bereit. Lass allgemeinen Code nicht von der Identität oder Begründung eines einzelnen Aufrufers abhängen. Gib jedem Schalter oder Parameter genau ein in sich schlüssiges Verhalten. Ersetze Wahrheitswerte, die Besitz, Zwischenspeicherung, E/A-Modus und Vorablesen bündeln, durch ausdrückliche Felder oder ein Optionsobjekt. Leite Richtlinien nicht aus beiläufigen Umsetzungsdetails wie Zwischenspeicherkennungen oder dem Leserzustand ab. Nutze Zusicherungen, engere Schnittstellen und klarere Namen, damit Verträge durchsetzbar werden. Gestalte neue Programmierschnittstellen einheitlich mit bestehender Benennung, Parameterreihenfolge, Rückgabetypen und Fehlerbehandlung. Verwende typsichere Optionen, gegebenenfalls einschließlich Ganzzahltypen fester Breite und Aufzählungen mit begrenztem Gültigkeitsbereich. Prüfe Optionswerte und gib eindeutige Fehler zurück. Gestalte dynamische Konfigurationsänderungen threadsicher und prüfe, wann sie wirksam werden. Bewahre Quelltext- und Binärkompatibilität, sofern eine inkompatible Änderung nicht außergewöhnlich gut begründet ist. Prüfe Anordnung, Symbole und Aufrufkonventionen, wenn eine öffentliche Binärschnittstelle bereitgestellt wird. Kennzeichne Elemente nach dem dokumentierten, mehrere Veröffentlichungen umfassenden Verfahren als veraltet und stelle eine Umstellungsanleitung bereit. Dokumentiere öffentliche Programmierschnittstellen mit Verwendung, Parameterbedeutung, Regeln zur Threadsicherheit, Leistungskosten und Kompatibilitätshinweisen. Stelle keine Umsetzungstypen Dritter über eine öffentliche Programmierschnittstelle bereit. ## Prüfe das Write-Ahead-Log und andere riskante Teile am gründlichsten Unterziehe Vorabprotokollierung, Speichertabellen, Verdichtung, Wiederherstellung und andere Datenbankkernpfade der gründlichsten Prüfung. Teste Kernänderungen mit unterschiedlichen Konfigurationen, Verdichtungsarten, Fehlern und nebenläufigen Arbeitslasten. Stelle sicher, dass die Verdichtung eingerichtete Grenzen einhält und Fälle ohne Datei oder mit nur einer Datei verarbeitet. Behandle öffentliche Headerdateien als die Oberfläche mit der größten Kompatibilitätswirkung. Behandle dauerhafte Tabellen- und Blockformate als langlebige Datenverträge. Prüfe Prüfsummen über verschiedene Komprimierungsarten, Blockgrößen, Beschädigungsfälle und Kompatibilitätsgrenzen hinweg. Teste Positionieren, Weitergehen, Zurückgehen, Löschen und Endpunktsemantik von Iteratoren. Halte Zwischenspeicherschlüssel eindeutig und stelle sicher, dass Vorablesen die Ressourcengrenzen einhält. Führe Leistungsmessungen für Tabellen-, Zwischenspeicher- und Hilfsprogrammänderungen durch, die in häufig ausgeführten Pfaden laufen können. Lege Zwischenspeichersynchronisierung, Speicherbesitz und Verdrängungsrichtlinie ausdrücklich fest. Halte optionale Hilfsprogramme von den Interna der Datenbank getrennt. Prüfe bei Optionen Typsicherheit, Validierung, Abkündigung und threadsichere dynamische Aktualisierungen. Teste bei internen Hilfsprogrammen Überlauf, Unterlauf, ungültige Eingaben und Zusicherungsverträge. Genehmige keine risikoreichen Änderungen an Format, Wiederherstellung, Verdichtung oder Zwischenspeicher ohne Nachweise aus Einzel-, Integrations-, Belastungs- und Leistungstests. ## Halte alle Build-Systeme synchron und baue auf jeder unterstützten Plattform Pflege beim Hinzufügen oder Entfernen einer Quelldatei jedes unterstützte Buildsystem. Aktualisiere zuerst die maßgebliche Quelldateiliste und erzeuge abgeleitete Builddateien mit dem zugelassenen Erzeugungswerkzeug neu. Bearbeite eine erzeugte interne Builddatei nicht von Hand. Suche in allen Builddefinitionen, Sprachen, Dokumentationen und Umsetzungen nach betroffenen Verweisen. Nutze innerhalb der Ressourcengrenzen die Prozessoranzahl des Rechners für parallele Builds. Verhindere, dass gemischte Buildarten inkompatible Objektdateien wiederverwenden. Aktiviere für manuelle Builds den Mechanismus des Buildsystems zur automatischen Bereinigung bei Konfigurationsänderungen. Unterstütze die Matrix des Projekts aus Betriebssystemen, Übersetzern, Standardbibliotheken, Fehlerprüfwerkzeugen und Buildarten. Berücksichtige, soweit eingerichtet, Linux, macOS, Windows, einheimische und Kreuzübersetzer, Release-Builds, Fehlerprüfwerkzeuge, Unity-Builds und Sprachanbindungen. Bevorzuge die Übertragbarkeitsabstraktionen des Projekts gegenüber unmittelbaren Plattformprogrammierschnittstellen. Sichere unvermeidliche plattformspezifische Headerdateien, Aufrufe, Attribute und eingebaute Funktionen durch Bedingungen ab. Binde jede Standardheaderdatei unmittelbar ein, statt dich auf mittelbare Einbindungen zu verlassen. Stelle sicher, dass Produktions- und Belastungsprogramme ohne Laufzeittypinformationen erstellt werden, wenn dies eine Projektvorgabe ist. Beschränke Laufzeitabwärtsumwandlungen auf Tests; verwende andernorts das geprüfte Hilfsmittel des Projekts für statische Umwandlungen. Führe Quelltextprüfungen aus, die nicht unterstützte Zeichen und andere mit der kontinuierlichen Integration unvereinbare Inhalte ablehnen. Verwende ASCII-Satzzeichen in Quelltextkommentaren und Zeichenketten, wenn das Repositorium dies verlangt. ## Schreibe reproduzierbare Tests, ohne dich auf Sleep-Aufrufe zu verlassen Passe die Prüftiefe dem Risiko an: Einzeltests für abgeschottetes Verhalten, Integrationstests für Wechselwirkungen und Belastungstests für Nebenläufigkeit und Leistung. Decke Grenzen, Fehlerpfade, Wiederherstellung, Plattformunterschiede und Rückfallfälle ab. Verwende tabellengesteuerte Fälle, wenn sich Eingaben unterscheiden, der geprüfte Vertrag aber gleich ist. Lagere Hilfsfunktionen für wiederholten Aufbau, Hin- und Rückumwandlungen sowie Zusicherungsfolgen aus. Halte deterministische Randfälle von zufallsbestimmter Abdeckung getrennt. Bevorzuge Zufallsstichproben gegenüber der vollständigen Kombination aller Parameter, wenn sie eine breitere nützliche Abdeckung liefern. Verwende die Zufallsquelle des Projekts und gib den Startwert aus, damit Fehler reproduzierbar sind. Warte nicht durch Schlafen auf nebenläufige Ereignisse. Steuere den Ablauf von Ausführungsfäden durch Synchronisierungspunkte oder ausdrückliche Signale. Begrenze die Laufzeit jedes Einzeltests durch eine festgelegte Zeitüberschreitung. Führe eine kleine Zahl gezielter Tests nacheinander und größere Mengen über die parallele Teststeuerung aus. Unterziehe neue Nebenläufigkeitstests wiederholt Belastungsprüfungen mit erzwungenen Kontextwechseln. Untersuche nur in der kontinuierlichen Integration auftretende instabile Fehler mit dem dafür vorgesehenen Nachstellwerkzeug des Projekts. Teste jede unterstützte Plattform, die von Pfaden, Programmierschnittstellen, Übersetzern oder Buildschaltern betroffen ist. Stelle sicher, dass Testfehler genügend Zustand melden, um die auslösende Konfiguration nachzustellen. Nimm neue Konfigurationsoptionen und Leistungsmerkmale in Belastungs- und Leistungstestabdeckung auf. Prüfe aktualisierte Tests vor der Einreichung auf Doppelungen und unbeabsichtigt gemeinsam genutzten Zustand. ## Füge Lizenz-Header hinzu und halte Dokumentation und Versionshinweise synchron Versehe jede neue Quelldatei mit dem vorgeschriebenen Lizenzkopf des Repositoriums. Bewahre in abgeleiteten Dateien zusätzlich zum Projektkopf die Urheberrechtshinweise der ursprünglichen Quelle. Verwende für jede Quellsprache das richtige Kommentarpräfix. Ersetze eine vorgeschriebene Doppellizenzbezeichnung nicht durch eine allgemeine Rechteerklärung. Führe nach Änderungen die automatische Formatierung aus und prüfe die entstandenen Unterschiede. Führe Werkzeuge zur Abhängigkeitspflege aus und lehne sachfremde Manifeständerungen ab. Bewerte beim Hinzufügen einer Funktion nützliche Messgrößen, ohne einen Leistungsverlust im häufig ausgeführten Pfad zu verursachen. Stelle leistungsbezogene Funktionen über das übliche Leistungsmesswerkzeug bereit. Halte Veröffentlichungshinweise kurz, nach außen gerichtet und auf für Nutzende sichtbares Verhalten beschränkt. Dokumentiere Komponentenentwürfe im Inhaltsverzeichnis des Teilsystems und in gezielten Kapiteln. Stelle bei Bedarf sicher, dass erzeugte Seiten oder Beiträge gültige Verfassermetadaten verwenden. Befolge bei neuen Programmierschnittstellen, Optionen oder Abkündigungen das dafür vorgesehene Verfahren des Repositoriums. Aktualisiere die Umstellungsanleitung, bevor du einen abgekündigten Schnittstellenbereich entfernst. Halte Umsetzung, Buildmetadaten, Tests, Dokumentation und Veröffentlichungshinweise synchron. Lass eine neue Quelldatei nicht über ein Buildsystem erreichbar sein, während sie in einem anderen fehlt. ## Bestehe einen sauberen Build und die Tests, bevor du eine Änderung freigibst Prüfe Korrektheit, Tests, Leistung, Kompatibilität, Vertragsgrenzen, Stil und Dokumentation als getrennte Freigabekriterien. Verlange Leistungsmessergebnisse für leistungskritische Änderungen. Verlange Belastungsabdeckung für neues nebenläufiges oder konfigurierbares Verhalten. Führe das vollständige Ziel für einen sauberen Build und Tests aus, nachdem gezielte Prüfungen bestanden wurden. Führe den strengeren Statusprüf-Build aus, der unbeachtete Fehlerergebnisse erkennt. Nutze die automatische Bereinigung, damit geänderte Buildschalter keine veralteten Objektdateien wiederverwenden können. Überwache lange Testläufe anhand der maschinenlesbaren Fortschrittsausgabe des Buildsystems. Verfolge Phase, erledigte Arbeit, Gesamtarbeit, Fehler, Prozentwert und begrenzte Fehlerdetails. Unterscheide Zusicherungsfehler von Abstürzen, Signalen, Zeitüberschreitungen und Infrastrukturfehlern. Bewahre Leistungsmessparameter und Testkonfigurationen zusammen mit den berichteten Nachweisen auf. Erstelle Leistungstests zur Messung im Release-Modus. Wechsle bei der Untersuchung eines Absturzes zu einem Debug-Build und führe vor der nächsten Messung einen sauberen Neuaufbau durch. Führe die für die betroffene Oberfläche erforderlichen Formatierungs-, Quelltext-, Build-, Test-, Fehlerprüfwerkzeug- und Plattformprüfungen aus. Führe unmittelbar betroffene Freigabekriterien nach Korrekturen aus der Prüfung erneut aus. Verkleinere eine das ganze Repositorium umfassende Konsistenzsuche nicht nur deshalb, weil manche Treffer unwahrscheinlich erscheinen. Genehmige erst, wenn Code, Verträge, Tests, Buildmetadaten, Dokumentation und gemessene Nachweise übereinstimmen.