Ein typsicheres Web-Framework ändern und den Datenbankcode in drei Schichten trennen

## Die festgelegte Entwicklungsumgebung des Repositorys nutzen und das zuständige Paket finden Rufen Sie die Entwicklungsumgebung über die im Quellcodearchiv festgelegte Umgebungsverwaltung auf, statt sich auf global installierte Werkzeuge zu verlassen. ### Einrichtung der Umgebung - Beginnen Sie im Stammverzeichnis des Quellcodearchivs und aktivieren Sie die genehmigte Entwicklungsbefehlsumgebung. - Verwenden Sie, sofern verfügbar, den zwischengespeicherten Ausführungspfad der Umgebung, um wiederholte Befehle zu beschleunigen. - Vergewissern Sie sich, dass Compiler, Paketverwaltung, Datenbankwerkzeuge und Dokumentationswerkzeuge aus der Umgebung mit festgeschriebenen Versionen stammen. - Verwenden Sie die Laufzeitversion, die im betreffenden Paket oder in der Dokumentationskonfiguration festgelegt ist. - Aktivieren Sie die Diagnoseprotokollierung nur bei Bedarf für die örtliche Fehlersuche und behandeln Sie den Diagnosebetrieb nicht als Produktionsstandard. ### Arbeitskontext Ermitteln Sie in einem Mehrpaket-Quellcodearchiv vor dem Ausführen von Befehlen, welches Paket für die Änderung zuständig ist. Bestimmen Sie dessen Quellverzeichnis, Testeinstiegspunkt, erzeugte Artefakte, öffentliche Module und örtliche Anweisungen, statt anzunehmen, dass alle Pakete denselben Arbeitsablauf verwenden. ## Erst schnell die Typen prüfen, dann alle Tests ausführen Nutzen Sie während der Bearbeitung die schnellste zuverlässige Rückmeldungsschleife und führen Sie anschließend die umfassendere maßgebliche Prüfung aus, die für die Übergabe erforderlich ist. ### Gezielte Bearbeitung - Bevorzugen Sie einen interaktiven Compiler, Typprüfer oder Modullader für schnelle Typmeldungen, wenn der vollständige Aufbau der Umgebung aufwendig ist. - Laden Sie in frühen Bearbeitungsphasen nur das geänderte Modul oder den gezielten Testeinstiegspunkt. - Interaktive Werkzeuge, die aus der Standardeingabe lesen, müssen Befehle und einen ausdrücklichen Beendigungspfad erhalten; andernfalls können sie unbegrenzt warten. - Wenn eine interaktive Sitzung das erneute Laden unterstützt, verwenden Sie sie nach Änderungen weiter, statt wiederholt die gesamte Umgebung neu aufzubauen. ### Testregistrierung - Fügen Sie neue Tests der maßgeblichen Testsammlung oder Erkennungskonfiguration des Pakets hinzu. - Vergewissern Sie sich, dass der gezielte Test tatsächlich über diesen Einstiegspunkt ausgeführt wird. - Führen Sie die vollständige Prüfung des Quellcodearchivs aus, wenn die Änderung fertig ist oder gemeinsames Verhalten, die Aufbaukonfiguration oder Paketgrenzen betroffen sind. - Stellen Sie eine gezielte Kompilierungsprüfung nicht als Beleg dafür dar, dass die vollständige Testsammlung erfolgreich ist. ### Entwicklungsserver Starten Sie örtliche Dienste nur aus der genehmigten Umgebung und im richtigen Arbeitsverzeichnis. Wenn der Entwicklungsserver von einer übergeordneten Anwendung oder einem übergeordneten Verzeichnis abhängt, stellen Sie diesen Kontext ausdrücklich her, bevor Sie seinen Einstiegspunkt aufrufen. ## Jedem Paket eine eigene Aufgabe geben und nur kleine öffentliche Module anbieten Ordnen Sie die Zuständigkeiten vor Codeänderungen zu, besonders in einem Quellcodearchiv, das Laufzeit, Entwicklungswerkzeuge, Vorlagen, Migrationen, Synchronisierung, Programmierschnittstellen, Tests und optionale Integrationen verbindet. ### Zuständigkeitsübersicht - Halten Sie Serverstart und Zwischenschicht von der Rahmenwerkkonfiguration getrennt. - Halten Sie Weiterleitung und URL-Erzeugung typsicher und von der Anfrageverarbeitung getrennt. - Trennen Sie Modelle, Prüfung, Authentifizierung, Hintergrundarbeit, Speicherung, E-Mail und Echtzeitaktualisierungen nach Zuständigkeit. - Halten Sie Codeerzeugung, Schemagestaltung und das Verhalten des Entwicklungsservers außerhalb des zentralen Laufzeitpakets, wenn die Architektur sie als Werkzeuge einordnet. - Behandeln Sie optionale Integrationen und serverseitige Komponenten als getrennte Pakete, statt ihre Abhängigkeiten in den Kern durchsickern zu lassen. ### Öffentliche Schnittstelle Stellen Sie nur die kleinste stabile Moduloberfläche bereit, die von Verbrauchern benötigt wird. Halten Sie rohe Anweisungen, interne Zusammensetzungen, vorangestellte Hilfsdefinitionen und Implementierungsmodule privat, damit sie sich weiterentwickeln können, ohne Aufrufende zu beeinträchtigen. Ergänzen Sie öffentliche Module und Funktionen um die vorgesehene Dokumentation der Programmierschnittstelle. ### Sprachkonventionen Befolgen Sie die in der Quellcodebasis etablierten Schreibweisen für reine Werte, kontextbezogene Parameter, Feldzugriffe, Vorlagen, Weiterleitung auf Typebene und Modelltypen. Bevorzugen Sie die bereits im Projekt verwendete Konvention gegenüber einer gleichwertigen Form, die die Uneinheitlichkeit vergrößert. ## Werte nie in den Abfragetext einfügen und nur die Sitzungsschicht nach außen zeigen Gliedern Sie den Datenbankzugriff in Anweisungs-, Transaktions- und Sitzungsschichten mit klarer Zuständigkeit für Kodierung, Unteilbarkeit und Verbindungen. ### Anweisungsschicht - Bewahren Sie rohe parametrisierte Abfragen zusammen mit ihren Eingabekodierern und Ergebnisdekodierern auf. - Verwenden Sie Platzhalter für jeden Laufzeitwert, statt Werte in den Abfragetext einzufügen. - Kodieren Sie die Möglichkeit von Nullwerten und die Datenbanktypen ausdrücklich. - Wählen Sie einen Dekodierer passend zur erwarteten Kardinalität: eine optionale Einzelzeile, eine erforderliche Einzelzeile oder mehrere Zeilen. - Belassen Sie Entscheidungen zur Zwischenspeicherung von Anweisungen bei der jeweiligen Anweisungsdefinition. ### Transaktionsschicht - Setzen Sie Anweisungen zu Geschäftsvorgängen zusammen, die Unteilbarkeit erfordern. - Halten Sie Verzweigungsregeln, Existenzprüfungen und Erstellungsentscheidungen innerhalb der Transaktion, wenn sie einen einzigen konsistenten Zustand beobachten müssen. - Stellen Sie idempotente Ergebnisse ausdrücklich dar, damit Aufrufende zwischen einem vorhandenen und einem neu erstellten Datensatz unterscheiden können. - Verwenden Sie eine unabhängige oder selektive Zusammensetzung nur, wenn die Vorgänge tatsächlich unabhängig sind und die beabsichtigte Transaktionsbedeutung bewahren. ### Sitzungsschicht - Stellen Sie die Sitzungsschicht als öffentliche Datenbankschnittstelle bereit. - Überlassen Sie den Sitzungen die Verbindungsausführung und Transaktionsgrenzen, während rohe Anweisungen und interne Transaktionen verborgen bleiben. - Verwenden Sie eine ausdrückliche Transaktion für Vorgänge mit mehreren Anweisungen und die direkte Ausführung einer Anweisung für eine einzelne unabhängige Abfrage. ## Isolationsstufe und Ergebnistyp an jede Datenbankoperation anpassen Richten Sie Isolation, Kardinalität und Ergebnistypen an der Bedeutung des Vorgangs aus, statt überall dasselbe Muster anzuwenden. ### Wahl der Isolation - Verwenden Sie eine starke Schreibtransaktion für kritische Vorgänge, deren Korrektheit von Serialisierung abhängt. - Verwenden Sie für Abfragen, bei denen Nebenläufigkeit eine Rolle spielt und schwächere Isolation vertretbar ist, eine geeignete Leseisolationsstufe. - Dokumentieren Sie jeden Vorgang, dessen Korrektheit von einer bestimmten Isolationsart abhängt. ### Ergebniskonventionen - Stellen Sie Ergebnisse mit null oder einer Zeile durch einen optionalen Wert dar. - Stellen Sie Ergebnisse mit vielen Zeilen durch den vorgesehenen Sequenztyp des Projekts dar. - Verwenden Sie Tupel für kleine interne Ergebnisse mit mehreren Spalten, wenn benannte Hüllen keine nützliche Grenze ergänzen würden. - Geben Sie einen ausdrücklichen Erfolgsindikator zurück, wenn eine Aktualisierung oder Löschung möglicherweise keine Zeile betrifft. - Geben Sie bei idempotenten Vorgängen sowohl zurück, ob Arbeit ausgeführt wurde, als auch den resultierenden Wert. ### Zusammensetzung von Kodierern und Dekodierern Wenn eine Kodiererbibliothek verschachtelte Paare zusammensetzt, passen Sie flache Eingabetupel bewusst an und belassen Sie die Zuordnung bei der Anweisung. Setzen Sie Dekodierer so zusammen, dass Spaltenreihenfolge, Möglichkeit von Nullwerten und Zeilenkardinalität erhalten bleiben. Ergänzen Sie gezielte Tests für Abweichungen, die Werte unbemerkt dem falschen Feld zuordnen könnten. ## Abhängigkeiten nur dort hinzufügen, wo sie gebraucht werden, und nie Force-Push nutzen Halten Sie Änderungen kompatibel, prüfbar und wiederherstellbar. ### Code und Abhängigkeiten - Verwenden Sie die vom Projekt bevorzugten Sprachformen, wenn sie die Verständlichkeit für Mitwirkende verbessern. - Dokumentieren Sie öffentliche Schnittstellen mit dem vorgesehenen Dokumentationssystem des Quellcodearchivs. - Beachten Sie die in der Quellcodebasis aktivierten Spracherweiterungen und führen Sie ohne konkreten Bedarf keine neuen Erweiterungen ein. - Fügen Sie Abhängigkeiten nur dem Paket hinzu, das sie verwendet. - Legen Sie untere und obere Kompatibilitätsgrenzen fest, die zum unterstützten Ökosystem passen. - Behandeln Sie experimentelle Abhängigkeiten als ausdrückliches Risiko und kapseln Sie sie hinter schmalen Schnittstellen. ### Git-Sicherheit - Führen Sie niemals `force-push` aus, auch nicht `force-with-lease`. - Wenn der entfernte Zweig fortgeschritten ist, führen Sie `fetch` aus, wenden Sie `rebase` oder `merge` auf den aktualisierten Verlauf an, lösen Sie Konflikte, prüfen Sie und führen Sie anschließend einen normalen `push` aus. - Verbergen Sie einen abgelehnten `push` nicht durch Umschreiben des gemeinsamen Verlaufs. - Halten Sie unbeteiligte erzeugte Dateien, Änderungen an Sperrdateien und örtliche Leistungseinstellungen aus dem Commit heraus. ## Lokale Ersetzungen aus Commits heraushalten und Dokumentation über den Release-Ablauf veröffentlichen Verwenden Sie beim Entwickeln örtliche Ersetzungen für Leistung und Abhängigkeiten, ohne sie in die gemeinsame Quellcodeverwaltung durchsickern zu lassen. ### Örtliche Leistungsanpassungen - Vorübergehende Schnellbauoptionen dürfen für örtliche Bearbeitung aktiviert werden, wenn das Projekt sie unterstützt. - Nehmen Sie eine ausschließlich örtliche Leistungsänderung nicht in einen Commit auf. - Prüfen Sie vor der Übergabe den tatsächlichen Änderungsvergleich, statt sich nur auf Indexkennzeichnungen zu verlassen, die Änderungen verbergen können. ### Örtliche Abhängigkeitsentwicklung Wenn Sie ein Rahmenwerk und eine nutzende Anwendung gemeinsam entwickeln: 1. Legen Sie die örtliche Arbeitskopie des Rahmenwerks an einem bewusst gewählten Entwicklungsort ab. 2. Richten Sie die Abhängigkeit der Anwendung über den unterstützten Ersetzungsmechanismus auf diesen örtlichen Pfad. 3. Aktivieren Sie die erforderliche Umgebung und aktualisieren Sie den Abhängigkeitszustand. 4. Testen Sie die Anwendung mit dem örtlichen Rahmenwerk. 5. Entfernen oder dokumentieren Sie die Ersetzung bewusst, bevor Sie gemeinsame Änderungen vorbereiten. ### Dokumentation und Veröffentlichung - Zeigen Sie die Dokumentation örtlich aus der dafür vorgesehenen Umgebung in einer Vorschau an. - Wenn die veröffentlichte Dokumentation getrennt gepflegt wird, aktualisieren Sie ihre Rahmenwerk- oder Dokumentationsabhängigkeit über den genehmigten Arbeitsablauf des Quellcodearchivs. - Nehmen Sie nur die für diese Aktualisierung erforderlichen Änderungen an Sperrdatei oder Quellcode in den Commit auf. - Stellen Sie Dokumentation oder Infrastruktur nur über den vorgesehenen Veröffentlichungsablauf bereit und bewahren Sie die erforderliche Reihenfolge von Abhängigkeitsaktualisierung, festgeschriebenem Zustand und Bereitstellung. - Wenn eine Rahmenwerkversion die Synchronisierung nachgelagerter Dokumentation erfordert, nehmen Sie diesen Schritt in die Veröffentlichungsprüfliste auf, statt sich auf das Gedächtnis zu verlassen.