Asynchrone Rust-Dienste bauen, die Abbrüche und Fehler überstehen

## Echten Code fertigstellen statt Mocks oder Stubs Setze das verlangte Verhalten vollständig von Anfang bis Ende um. Ersetze fehlende Produktivlogik nicht durch Scheinobjekte, Ausweichimplementierungen, Funktionsgerüste oder Abkürzungen, die nur für Prüfungen bestimmt sind. - Verwende echte Abhängigkeiten und den tatsächlichen Integrationsweg. - Verändere Prüfungen nicht so, dass sie eine fehlerhafte Implementierung verbergen. - Vermeide Umgehungslösungen für die Umgebung, die eine erforderliche Einrichtung überspringen. - Halte unvermeidbare unvollständige Arbeit ausdrücklich im daraus entstehenden Plan oder in der Spezifikation fest. - Behaupte niemals ohne Nachweis aus dem von den Nutzern tatsächlich verwendeten Ablauf, dass eine Funktion arbeitet. Autonome Ausführung bedeutet, den sorgfältigen Weg vollständig zu gehen, nicht die Fertigstellungskriterien abzuschwächen. ## Dieselben Designentscheidungen auf alle verwandten Datenarten anwenden Wenn ein System mehrere verwandte Signal- oder Datenfamilien verarbeitet, entwirf gemeinsames Verhalten für alle, selbst wenn derzeit eine Familie Vorrang hat. - Ermittle die Semantik, die Aufnahme, Speicherung, Suche, Auswertung und Lebenszyklusverwaltung gemeinsam haben. - Halte familienspezifische Optimierungen hinter ausdrücklich definierten Grenzen. - Prüfe, dass gemeinsame Entscheidungen nicht versehentlich die zuerst implementierte Familie bevorzugen. - Bewahre über alle Wege hinweg ein einheitliches Verhalten bei Fehlern, Konfiguration und Beobachtbarkeit. - Dokumentiere beabsichtigte Unterschiede, anstatt die Implementierungen auseinanderdriften zu lassen. Die Priorisierung darf die Lieferreihenfolge bestimmen, aber nicht unbemerkt die Architektur verengen. ## Sicherheit zuerst, dann Geschwindigkeit, dann Bequemlichkeit Verwende diese technische Rangfolge: zuerst Sicherheit, dann Leistung, zuletzt Bequemlichkeit für die Entwicklung. Optimiere erst, nachdem die Invarianten und das Fehlerverhalten verstanden sind. - Weise ungültige Eingaben an öffentlichen Grenzen zurück. - Lege ausdrückliche Grenzwerte als benannte Konstanten fest und gib strukturierte Fehler zurück, wenn sie überschritten werden. - Verschleiere Fehler von Abhängigkeiten, Speicherung oder Netzwerk nicht durch eine erfolgreiche Ausweichlösung. - Behandle einen unerwarteten Zustand als Fehler oder verletzte Invariante, nicht als erfolgreiche wirkungslose Operation. - Erlaube fehlende optionale Daten nur, wenn der Vertrag sie ausdrücklich als optional festlegt. Leistungsverbesserungen müssen die Korrektheit bei Fehlern, Wiederholungsversuchen, Abbruch und teilweisem Fortschritt erhalten. ## Debug-Assertions für interne Regeln, Fehlerwerte für ungültige Eingaben nutzen Verwende nur bei der Fehlersuche aktive Zusicherungen, um interne Invarianten zu dokumentieren, die Prüfer nachvollziehen können. Verwende behebbare Fehlerergebnisse für ungültige Nutzereingaben, externe Daten und Laufzeitbedingungen, weil solche Zusicherungen in optimierten Programmfassungen entfallen können. - Reiche Bibliotheksfehler mit `Result` und dem Operator `?` weiter. - Vermeide in wiederverwendbarem Bibliotheksquelltext Methoden, die Werte bedingungslos entnehmen. - Bewahre aussagekräftige Fehlertypen, anstatt jeden Fehler einzuebnen. - Verwende fehlbare Dateisystem- und Metadatenoperationen, wenn ihre Fehler Informationen tragen. - Ergänze Zusammenhang, ohne die ursprüngliche Ursache zu verwerfen. - Ignoriere einen Fehler niemals stillschweigend durch eine ungenutzte Zuweisung. Ein unmöglicher Zustand muss deutlich genug fehlschlagen, um die Diagnose zu ermöglichen. ## Asynchronen Code sicher halten, wenn Tasks abgebrochen werden Gehe davon aus, dass asynchrone Arbeit an jeder Unterbrechungsstelle abgebrochen werden kann. Strukturiere Zustandsübergänge so, dass ein Abbruch weder einen teilweise aktualisierten Zustand sichtbar macht noch Daten verliert. - Bevorzuge für abbruchsempfindlichen veränderlichen Zustand Besitz nach dem Akteurmodell und Nachrichtenübermittlung. - Halte eine Sperre nicht über eine asynchrone Unterbrechungsstelle hinweg. - Verwende synchrone kritische Abschnitte, wenn eine Änderung atomar erfolgen muss. - Brich kooperativ über ein Abbruchsignal ab, statt Aufgaben willkürlich zu beenden. - Fixiere in Auswahlschleifen ein laufendes Zukunftsobjekt und setze es fort, statt es neu zu erzeugen und zu verwerfen. - Gestalte Herunterfahren und Bereinigung idempotent. Wähle in Programmen nach dem Akteurmodell und in asynchronen Programmen eine einfachere Vervielfältigung oder gemeinsamen Besitz, wenn dadurch Besitz- und Abbruchverhalten sicherer werden. ## Typen und Besitz klar halten und große Dateien aufteilen Verwende etablierte Domänenkennungen und Typaliase, statt neue Konzepte als bloße Zeichenketten weiterzugeben. Lass das Typsystem Werte unterscheiden, die nicht vermischt werden dürfen. - Vermeide das Verdecken von Namen innerhalb einer Funktion, wenn es Zustandsübergänge unklar macht. - Gib Referenzen zurück, wenn der Besitz lokal bleibt und eine Vervielfältigung unnötig ist. - Verwende ausdrücklichen gemeinsamen Besitz, wenn Werte Aufgabengrenzen überschreiten. - Bevorzuge prozedurale Schleifen, wenn Iteratorverkettungen einen fehlbaren Steuerfluss schwer lesbar machen. - Teile übergroße Dateien und Funktionen nach zusammenhängenden Verantwortlichkeiten auf. - Halte öffentliche Schnittstellen von Implementierungsdetails getrennt. Lesbarkeit ist ein Werkzeug für Zuverlässigkeit, wenn Programmtext asynchrone Zustände koordiniert. ## Über die echte Dienstschnittstelle testen, die Nutzer verwenden Erkläre eine Funktion erst dann für fertig, wenn sie über die echte öffentliche Gesamtkette ausgeführt wurde. Wenn Nutzer ein Verhalten über ein Netzwerkprotokoll, eine Vermittlungsschicht oder eine Dienstgrenze erreichen, prüfe es über diese Grenze, statt unmittelbar eine interne Funktion aufzurufen. 1. Starte den echten Dienst mit einer repräsentativen Konfiguration. 2. Sende Eingaben über die unterstützte Aufnahme- oder Befehlsschnittstelle. 3. Rufe das Ergebnis über die unterstützte Abfrage- oder Antwortschnittstelle ab. 4. Überprüfe Dauerhaftigkeit, Fehlerzuordnung und beobachtbare Nebenwirkungen. 5. Bestätige, dass internes und öffentliches Verhalten übereinstimmen. Interne Prüfungen sind nützlich, ersetzen aber keinen Nachweis über den Produktivweg. ## Testarten nach Zweck wählen, auch Fehlertests Verwende schnelle Einzelprüfungen für isolierte Logik, eigenschaftsbasierte Prüfungen für breite Zustandsräume, Prüfungen mit Fehlerinjektion für Widerstandsfähigkeit und Integrationsprüfungen für das vollständige Dienstverhalten. - Grenze Eingaben für eigenschaftsbasierte Prüfungen so weit ein, dass sie nützliche Gegenbeispiele erzeugen. - Verwende echte Dienstprüfaufbauten, wenn Speicher- oder Protokollverhalten von Bedeutung ist. - Beschränke Wiederholungsversuche auf Prüfserien, die nichtdeterministische Ablaufplanung bewusst tolerieren. - Führe eine Abdeckung der Fehlerstellen aus, wenn Änderungen Wiederherstellung oder Zustandsübergänge betreffen. - Ergänze für jede neue öffentliche Schnittstelle eine Integrationsprüfung. - Prüfe den Fehlerweg ebenso bewusst wie den Erfolgsweg. Lass nicht zu, dass wiederholte Versuche einen deterministischen Defekt in einen scheinbaren Erfolg verwandeln. ## Prüfungen mit der festgelegten Werkzeugkette und den Befehlen des Repositorys ausführen Führe Programmerstellung, Formatierung, statische Quelltextprüfungen, Funktionsprüfungen, Dokumentationsprüfungen, Lizenzprüfungen, Abhängigkeitsprüfungen und Rechtschreibprüfungen mit den im Repositorium festgelegten Befehlen aus. - Verwende die festgeschriebene Werkzeugkette und den erforderlichen Kanal des Formatierers. - Starte deklarierte lokale Dienste vor den Integrationsprüfserien und beende sie anschließend. - Übergib die Prüfkonfiguration über dokumentierte Umgebungsvariablen, ohne echte Zugangsdaten einzubetten. - Führe zuerst das eng begrenzte betroffene Paket und danach die Prüfserie des gesamten Arbeitsbereichs mit allen Funktionsmerkmalen aus. - Behandle jede Warnung der statischen Quelltextprüfung als zu lösende Arbeit oder begründe sie mit der kleinsten gezielten Ausnahme. - Stelle sicher, dass jede Änderung für sich übersetzt werden kann, nicht nur als Teil einer später darauf aufbauenden Änderung. Unmittelbare Befehle sind nur zulässig, wenn sie die vom maßgeblichen Arbeitsablauf vorgenommene Einrichtung bewahren. ## Architekturänderungen in drei Arten von Aufzeichnungen festhalten Verfolge architektonische Änderungen durch drei einander ergänzende Aufzeichnungen: - **Eigenschaften:** vorausschauende Anforderungen, welche die Architektur erfüllen muss; - **Lücken:** Einschränkungen, die durch Vorfälle, Prüfungen oder Verhalten im Produktivbetrieb entdeckt wurden; - **Abweichungen:** beabsichtigte Abweichungen von der bevorzugten Architektur einschließlich Begründung und Einschränkungen. Verknüpfe Quelltextänderungen mit der einschlägigen Aufzeichnung, wenn sie Systemgarantien verändern. Halte formale Modelle, Simulationsabläufe, Entscheidungsaufzeichnungen und Umsetzungsstand voneinander getrennt, damit ein angestrebter Entwurf nicht mit fertiggestelltem Verhalten verwechselt wird. Aktualisiere die Aufzeichnung, wenn neue Nachweise die Architektur verändern, nicht nur wenn eine neue Funktion angekündigt wird. ## Auf Review-Kommentare im bestehenden Thread antworten Erleichtere die Überprüfung von Änderungen, indem du Änderungsvergleiche auf das Wesentliche beschränkst und Erklärungen an die jeweilige Entscheidung anfügst. - Antworte auf einen Überprüfungskommentar in seinem bestehenden Gesprächsfaden, statt an derselben Stelle einen getrennten Kommentar anzulegen. - Prüfe über die Oberfläche der Bereitstellungsplattform, dass die Antwort dem vorgesehenen Ausgangskommentar zugeordnet ist. - Erkläre, warum eine nicht offensichtliche Invariante, Ausnahme, Vervielfältigung oder Abweichung notwendig ist. - Trenne nicht zusammenhängende Umstrukturierungen von funktionalen Änderungen. - Aktualisiere fortlaufend gepflegte Leitlinien, wenn ein wiederkehrendes Fehlermuster eine dauerhafte Regel erkennen lässt. Saubere Überprüfungen bewahren den Zusammenhang und verhindern, dass dasselbe Problem in parallelen Gesprächen mehrfach gelöst wird. ## Vor der Fertigmeldung alle Prüfungen im finalen Diff bestehen Überprüfe vor der Fertigmeldung den abschließenden Änderungsvergleich und bestätige: - alle einschlägigen statischen Quelltextprüfungen bestehen ohne unerklärte Warnungen; - die Formatierungsprüfungen bestehen für jede geänderte Quell- und Prüfdatei; - es bleiben keine bedingungslose Entnahme, stille Fehlerunterdrückung oder unbegründete Vervielfältigung zurück; - die Prüfungen über Produktivschnittstellen und die betroffenen Integrationsprüfungen bestehen; - erforderliche Kopfzeilen, Protokollkonventionen, Dokumentation und Abhängigkeitsprüfungen bestehen; - neue Dateien und Funktionen bleiben eng ausgerichtet und wartbar; - keine Zugangsdaten oder vertraulichen Werte sind enthalten. Behebe Fehler an ihrer Ursache. Deaktiviere keine Prüfungen, schwäche keine Funktionsprüfungen und umgehe nicht den Produktivweg, nur um ein erfolgreiches Ergebnis zu erhalten.