Synchrone und asynchrone Version einer Clientbibliothek gemeinsam ändern, ohne die API zu brechen

## Vor dem Ändern das öffentliche Verhalten festhalten, das gleich bleiben muss Bestimme vor der Bearbeitung das öffentliche Verhalten, die unterstützten Laufzeitversionen, die maßgebliche Architektur und die kleinste für die Änderung zuständige Dateigruppe. - Behandle öffentliche Signaturen, Argumentnamen, Standardwerte, Rückgabetypen, Ausnahmen und das Verhalten in Grenzfällen als Kompatibilitätsverträge. - Ermittle alle parallelen Umsetzungen desselben Verhaltens, etwa synchrone und asynchrone Clients. - Bestimme die beteiligten Ebenen für Weiterleitung, Auswertung, Richtlinien, Verbindungen und Antwortformung. - Lies benachbarte Umsetzungen, Prüfungen und Typüberladungen, bevor du ein Muster auswählst. - Bewahre die bestehende Protokoll- und Serversemantik, sofern die angeforderte Änderung nicht ausdrücklich etwas anderes verlangt. - Weite die Aufgabe nicht auf sachfremde Aufräumarbeiten aus. Wenn das angeforderte Verhalten einer dokumentierten unveränderlichen Bedingung widerspricht, halte an und mache den Widerspruch sichtbar, anstatt den Vertrag stillschweigend neu zu bestimmen. ## Synchronen und asynchronen Client auf dieselbe Weise ändern Wenn eine Bibliothek gleichwertige Clientausführungen bereitstellt, behandle ihre Gleichwertigkeit als zwingende Eigenschaft. 1. Ordne das geänderte synchrone Symbol seinem asynchronen Gegenstück zu oder umgekehrt. 2. Vergleiche Signaturen, Überladungen, Typangaben, Standardwerte, Rückgabeformen, Fehler und Nebenwirkungen. 3. Wende in beiden Ausführungen gleichwertiges Verhalten an, sofern ein dokumentierter Laufzeitunterschied dies nicht unmöglich macht. 4. Halte gemeinsame Befehlsschnittstellen, Weiterleitungstabellen, Rückruffunktionen der Auswertung und Richtlinienmetadaten konsistent. 5. Ergänze zusammengehörige Prüfungen, wenn beide Ausführungen das Verhalten anbieten. Verwende die in der Codebasis festgelegte Typschreibweise und die bestehenden Überladungskonventionen. Wenn nur eine Seite geändert werden soll, halte den konkreten architektonischen Grund fest und prüfe, ob die Abweichung beabsichtigt ist. ## Nur die zuständige Schicht ändern und vorhandene Hilfsfunktionen nutzen Bevorzuge eine gezielte Änderung, die vorhandene Hilfsfunktionen und Konventionen wiederverwendet. - Ändere nur die Ebene, die für das Verhalten zuständig ist. - Bewahre öffentliche Programmierschnittstellen und die Fehlersemantik. - Vermeide neue Abhängigkeiten, sofern die vorhandenen Mittel die Anforderung erfüllen können. - Vermeide neue Abstraktionen, wenn eine bestehende Hilfsfunktion oder ein vorhandenes Muster ausreicht. - Halte Einbindungen auf das Nötigste beschränkt und auf Modulebene, sofern eine verzögerte Einbindung nicht technisch erforderlich ist. - Aktualisiere Dokumentationszeichenketten bei Verhaltensänderungen und halte sie mit den Typen im Einklang. Korrektheit steht an erster Stelle. Optimiere erst, nachdem das Verhalten korrekt ist, und tausche Korrektheit niemals gegen weniger Speicherzuweisungen oder eine schnellere Ausführung ein. ## Häufige Pfade nicht verlangsamen und das Protokollverhalten nicht ändern Prüfe Änderungen an häufig ausgeführten Pfaden auf vermeidbare Speicherzuweisungen, wiederholte Auswertungen, doppelte Arbeit und große vorübergehende Strukturen. - Verwende etablierte Hilfsfunktionen und zwischengespeicherte Metadaten erneut. - Bewahre die Auswahl des Übertragungsprotokolls unabhängig von der benutzerseitigen Antwortformung. - Halte Weiterleitungs- und Zusammenführungsrichtlinien mit der Befehlssemantik im Einklang. - Behandle Weiterleitungen, Wiederholungsversuche, Topologieunterschiede und Fehlerweitergabe ausdrücklich, wenn sie maßgeblich sind. - Vereinheitliche einen Grenzfall, den der zugrunde liegende Dienst ausdrücklich unterscheidet, nicht stillschweigend. Leistungsänderungen müssen dasselbe beobachtbare Verhalten bewahren. Wenn eine Optimierung die Korrektheit oder Gleichwertigkeit erschwert, wähle die einfachere korrekte Umsetzung. ## Vom fehlschlagenden Testfall bis zur vollen Testmatrix testen Baue die Nachweise mit zunehmendem Umfang auf: 1. Ergänze oder aktualisiere eine deterministische Prüfung, die vor der Korrektur fehlschlägt. 2. Führe die kleinste maßgebliche Prüfung oder Prüfsammlung aus. 3. Führe die gespiegelte Abdeckung für synchrone und asynchrone Ausführungen aus. 4. Prüfe sinnvolle Kombinationen aus Protokoll, Antwortmodus, Topologie oder wahlweisen Funktionen. 5. Führe die vom Projekt verlangten statischen Quelltextprüfungen, Formatierungsprüfungen und Typprüfungen aus. 6. Führe die vollständige unterstützte Prüfmatrix aus, wenn die Änderung gemeinsames Verhalten beeinflussen kann. Schwäche keine Prüfaussagen, entferne keine Abdeckung und ordne Fehler nicht allein deshalb neu ein, damit die Prüfsammlung besteht. Prüfungen, die eine externe Infrastruktur benötigen, müssen klar von den vorgegebenen örtlichen Prüfsammlungen getrennt bleiben. ## Die abschließenden Änderungen auf Debug-Code und Abweichungen zwischen synchron und asynchron prüfen Untersuche vor dem Abschluss die gesamte Änderung und vergewissere dich: - Nur maßgebliche Dateien und Zeilen wurden geändert. - Es bleiben weder Diagnosecode noch versehentlich entfernte Logik oder sachfremde Formatänderungen zurück. - Öffentliche Programmierschnittstellen und das Fehlerverhalten sind unverändert, sofern keine ausdrückliche Änderungsabsicht besteht. - Gespiegelte Umsetzungen und Typangaben bleiben im Einklang. - Die Prüfungen decken Erfolgsfälle, Grenzfälle und Fehlerpfade ab. - Statische Quelltextprüfungen und erforderliche Prüfsammlungen bestehen. - Die Dokumentation stimmt mit dem umgesetzten Verhalten überein. - Es wurden keine unnötigen Abhängigkeiten, Speicherzuweisungen oder Abstraktionen eingeführt. Behebe jedes gefundene Problem und wiederhole die betroffenen Prüfungen. Berichte, was geändert und geprüft wurde und welches externe Szenario ausdrücklich ungeprüft blieb, ohne eine umfassendere Prüfung zu behaupten.