Zustandsbehaftete UI-Bibliothek in kleinen Schritten ändern, ohne bestehende Nutzer zu stören

## Den Besitzer des Zustands finden und den Zustand nur dort ändern, wo die Bibliothek es erlaubt Bestimme zuerst den Eigentümer des Zustands, die Aktualisierungsgrenze und den öffentlichen Schnittstellenvertrag, die von der Anforderung betroffen sind. Lies in einem unveränderlichen Zustandsmodell aus einem konsistenten Schnappschuss und ändere den Zustand nur innerhalb des von der Bibliothek vorgesehenen Aktualisierungskontexts. Behandle Verweise auf Knoten oder Entitäten als versionsgebundene Referenzen; übertrage keine Annahmen über veränderliche Zustände über Aktualisierungsgrenzen hinweg. Halte Funktionsregistrierungen, Befehle, Transformationen und Ereignisbeobachter innerhalb ihres dokumentierten Lebenszyklus. Bevorzuge für neue Arbeiten den aktuellen Erweiterungs- oder Kompositionsmechanismus und erhalte zugleich jeden weiterhin unterstützten älteren Integrationsweg. Sorge für einen eindeutigen Bereinigungsweg zu jeder Registrierung und bewahre Serialisierungsformate, die bestehende Nutzer weiterhin laden könnten. ## Mit syntaxbewusster Suche arbeiten und die Änderung klein halten Verwende syntaxbewusste Suche und Ersetzung, wenn eine Änderung Importe, Aufrufstellen, Typangaben oder strukturierten Quelltext betrifft. Zeilenorientierte reguläre Ausdrücke können mehrzeilige Formen übersehen und unbeteiligte Bezeichner erfassen. Prüfe mögliche Treffer im Syntaxbaum, bevor du eine umfangreiche Ersetzung anwendest. Richte die Änderung am gewünschten Verhalten aus und halte sie örtlich begrenzt. Verwende fachbezogene Namen, Schutzklauseln für ungültige oder bereits behandelte Zustände und einen klar erkennbaren Erfolgsweg. Lagere Hilfsfunktionen nur dann aus, wenn sie eine Verantwortung benennen oder den Aufrufer vereinfachen. Vermische keine beiläufige Umstrukturierung, Diagnoseprotokollierung, vorläufigen Namen oder sachfremde Formatierung mit der endgültigen Änderung. Wenn auf Modulebene eine nebenwirkungsfreie Erzeugerfunktion angelegt wird, halte die projektübliche Kennzeichnung zur Entfernung ungenutzten Codes ein. Erweitert sich die Familie dieser Erzeugerfunktionen, aktualisiere auch die Regel, die diese Kennzeichnung erzwingt. ## Öffentliche APIs kompatibel halten und document und window des Elements selbst nutzen Gehe davon aus, dass externer Quelltext von vorhandenen öffentlichen Namen, Signaturen, Verhaltensweisen und serialisierten Daten abhängt. Bevorzuge ergänzende Programmierschnittstellen und optionale Parameter. Ist eine inkompatible Änderung unvermeidbar, erhalte den bisherigen Weg und kennzeichne ihn vor seiner Ausmusterung als veraltet. Prüfe sowohl den aktuellen als auch den kompatiblen Weg. Pflege jedes unterstützte Typsystem und jede erzeugte Deklarationsoberfläche, die von der Programmierschnittstelle berührt wird. Browserseitiger Quelltext muss das zugehörige document und window aus der betreffenden Wurzel oder dem betreffenden Element beziehen, statt sich auf globale Umgebungsobjekte zu verlassen. Verwende kontextbewusste Hilfsfunktionen für Auswahl, Fokus, Ereignisziel und das Durchlaufen übergeordneter Elemente, damit Schattenwurzeln und eingebettete Dokumente nicht unbemerkt aus der falschen Umgebung lesen. Ermittle bei Änderungen an Serialisierung, Anforderungsverarbeitung, Adressen, HTML- oder Skriptausgaben, Dateisystempfaden, Authentifizierung oder Abhängigkeiten die nicht vertrauenswürdige Eingabe und die nächstgelegene prüfende Schutzvorkehrung. Bevorzuge ein bei Fehlern ablehnendes Verhalten, halte Geheimnisse aus Protokollen und Ergebnissen fern und prüfe bei jedem Protokoll sowohl die schreibende als auch die lesende Seite. ## Zuerst einen fehlschlagenden Test schreiben und zwischen Unit- und echtem Browsertest wählen Definiere bei einer Verhaltensänderung oder Fehlerbehebung zuerst die beobachtbare Invariante. Ergänze oder aktualisiere den nächstgelegenen gezielten Test, führe ihn nach Möglichkeit vor der Umsetzung aus und bestätige, dass er aus dem erwarteten Grund fehlschlägt. Nimm die kleinste Änderung vor, die ihn erfüllt, führe den gezielten Test erneut aus und erweitere die Prüfung anschließend nur auf den von der berührten Oberfläche verlangten Umfang. Verwende Einzeltests in einer simulierten Umgebung für Logik, die nicht vom tatsächlichen Layout oder Auswahlverhalten abhängt. Nutze echte Browsertests für Layout, Auswahl, Fokus, Schattenwurzeln oder dokumentübergreifendes Verhalten. Setze durchgängige Systemtests nur für Navigation, die vollständige Anwendungsintegration oder Protokolle ein, die ein laufendes System benötigen. Erstelle das konkrete Ergebnis, das der Test verwendet, bevor du dich auf sein Resultat stützt. Ersetze einen gezielten Test nicht ohne Grund durch einen umfassenden Befehl für den gesamten Quelltextbestand. Eine bestandene, sachfremde Testsammlung belegt die geänderte Grenze nicht. ## Vor dem Abschluss die Änderungen prüfen und einen Veröffentlichungshinweis ergänzen Prüfe vor dem Abschluss den Änderungssatz aus der Sicht eines neu hinzukommenden Mitwirkenden. Bestätige, dass Namen die fachliche Bedeutung zeigen, Randfälle ausdrückliche Schutzklauseln verwenden, der Hauptweg lesbar ist, die Bereinigung vollständig erfolgt und kein öffentlicher Schnittstellenvertrag unbeabsichtigt geändert wurde. Führe das vom betroffenen Paket verlangte Formatierungsprogramm, die Regelprüfung, die Typprüfung oder die Schnappschussprüfung der Programmierschnittstelle aus. Füge den vom Quelltextbestand vorgesehenen Veröffentlichungshinweis oder Änderungseintrag hinzu, wenn sich veröffentlichtes Verhalten ändert. Beschreibe die nutzerseitige Korrektur oder Funktion statt der Umsetzungsmechanik. Halte private Sitzungsverweise, Zugangsdaten und ausschließlich interne Verweise aus Texten zu Versionsbeiträgen und Änderungsanträgen heraus und dokumentiere die gezielten Testergebnisse, die die Änderung belegen.