Ein Konsolen-UI-Toolkit nach seiner aktuellen Doku ändern und am echten Bildschirm prüfen

## Der aktuellen Repository-Doku folgen, nicht Mustern älterer Versionen - Wenn ein Projekt eine grundlegende Neuentwicklung ankündigt, ist davon auszugehen, dass früher erlernte Muster trotz vertrauter Bezeichnungen unvereinbar sein können. - Vor dem Entwerfen, Bearbeiten oder Prüfen von Code die aktuelle Einführung zur Umstellung im Repository lesen. - Das aktuelle Muster für eine minimale Anwendung sowie Begriffe, Lebenszyklus und Hinweise zur Verträglichkeit aus der versionierten Quelldokumentation verwenden. - Projektverfassung, Beitragsleitfaden, maschinenlesbaren Kontext und untergeordnete Regeln höher gewichten als Erinnerungen oder Beispiele aus früheren Versionen. - Wenn aktuelle Dokumentation und Vorwissen einander widersprechen, dem aktuellen Repository folgen und die Abweichung festhalten, statt beide Entwürfe zu vermischen. ## Vor dem Start klären, ob eine App gebaut oder das Toolkit selbst geändert wird - Die Anfrage zuerst als Anwendungsentwicklung, Beitrag zum Werkzeugsatz, Fehlerbehebung oder visuelle Aufzeichnung und Prüfung einordnen. - Für Anwendungen, die den Werkzeugsatz verwenden, den eigenen Anwendungsleitfaden und die Mustersammlung nutzen. - Für Bibliotheksfunktionen und Fehler das Beitragsverfahren nutzen. - Für sichtbare UI-Änderungen und Nachweise von Bedienabläufen das Aufzeichnungsverfahren nutzen. - Vor Änderungen in diesen Bereichen die grundlegende Dokumentation zu Lebenszyklus, Ansichtshierarchie, Anordnung, abbrechbaren Ereignissen und Fachbegriffen lesen. - Nur für Beiträge bestimmte Interna weder auf Anwendungsbeispiele anwenden noch Abkürzungen aus Anwendungen für Arbeiten an der Kernbibliothek verwenden. ## Checklisten vor jeder Bearbeitung und nach dem Schreiben von Code durchgehen - Vor jeder Dateibearbeitung die Aktualisierungsprüfliste des Repositorys für häufige Fehler und örtliche Einschränkungen durchgehen. - Nach dem Schreiben oder Ändern von Code die vollständige Prüfliste nach der Erzeugung anwenden. - Für jedes betroffene Thema die ausführliche Regel lesen, darunter Formatierung, Typdeklarationen, Erzeugungssyntax, Ereignismuster, Unicode-Text, Codeanordnung, Dokumentation, Tests, Diagnose und empfindliche Bereiche. - Im Planungsmodus im vorgesehenen Planverzeichnis einen Markdown-Plan mit Umsetzungsschritten, betroffenen Dateien, Möglichkeiten zur Wiederverwendung und Prüfung anlegen. - Den Plan am tatsächlichen Umfang ausrichten und aktualisieren, wenn neue Belege den Umsetzungsweg ändern. ## Neue Tests standardmäßig in die parallele Suite legen - Abhängigkeiten wiederherstellen, einmal erstellen und gezielte Tests ohne erneute Erstellung ausführen, solange das Erstellungsergebnis noch aktuell ist. - Neue Tests grundsätzlich in die parallel ausführbare Testsammlung einordnen. - Die nicht parallele Sammlung nur verwenden, wenn ein prozessweiter statischer Zustand unvermeidbar ist, und diese Abhängigkeit erläutern. - Einer veralteten Testsammlung, die neu geschrieben oder entfernt werden soll, niemals neue Abdeckung hinzufügen. - Während der schrittweisen Arbeit eine einzelne Methode oder Klasse auswählen und nach bestandenem gezieltem Test auf das zugehörige Projekt ausweiten. - Vor der Wahl von Integrations-, Belastungs-, Leistungs-, Parallel- oder Nichtparalleltests das Testverzeichnis heranziehen. ## Das laufende Terminal aufzeichnen, um UI-Änderungen zu prüfen - Eine visuelle Änderung nicht ausliefern, ohne die laufende Benutzeroberfläche beobachtet zu haben. - Die Anwendung in einem Pseudoterminal ausführen, repräsentative Tasteneingaben einspeisen und die dargestellte Sitzung aufzeichnen. - Die maschinenlesbare Aufzeichnung Bild für Bild lesen, um das tatsächlich Erschienene zu prüfen, statt sich nur auf eine menschliche Vorschau zu verlassen. - Ein visuelles Ergebnis beifügen, wenn Prüfende Erscheinungsbild oder Bedienung beurteilen müssen. - Für reproduzierbare Zusicherungen Eingabeeinspeisung innerhalb des Prozesses, virtuelle Zeit und Bildschirmaufnahmen auf Treiberebene verwenden. - Anordnung, Fokus, Eingabeverarbeitung, Unicode-Grapheme, Abbruch und Neuzeichnen auf der von der Änderung betroffenen Ebene prüfen. ## Die genauen Leerzeichen- und Typregeln des Repositorys einhalten - Die im Repository vorgeschriebenen Abstände bei Aufrufen und Indexzugriffen sowie die Regeln für Klammerstellung und Leerzeilen beibehalten. - Außer bei den wenigen vom örtlichen Leitfaden zugelassenen eingebauten primitiven Typen ausdrückliche Typen verwenden. - Wo vorgeschrieben, zieltypisierte Objekterzeugung und die Syntax für Sammlungsausdrücke bevorzugen. - Je Datei nur einen public- oder internal-Typ verwenden. - Elemente und zugehörige private Felder gemäß der Regel zur Codeanordnung sortieren. - Für ungenutzte Parameter von Rückruffunktionen die Verwerfkonvention des Repositorys verwenden. - Formatierungswerkzeug und Prüfungen nach der Erzeugung ausführen; Stilunterschiede nicht als bloße Äußerlichkeit abtun. ## Frühe Rücksprünge und die Begriffe des Projekts verwenden - Vorgelagerte Abbruchprüfungen und frühes Verlassen bevorzugen; Bedingungen umkehren, statt den erfolgreichen Pfad tief zu verschachteln. - Dieselbe Regel zum frühen Verlassen auf Methoden, Rückruffunktionen und Schleifen anwenden. - Die Begriffe des Projekts für Enthaltensein einheitlich verwenden und allgemeine Beziehungsbegriffe für Verweise ohne Enthaltensein vorbehalten. - Code zunächst durch Namen, Typen und Aufbau selbsterklärend gestalten, bevor Kommentare hinzugefügt werden. - In Referenz-, Anleitungs- und API-Dokumentation zuerst das Ziel nennen und danach eine direkte Handlungsanweisung geben. - Öffentliche Verträge, das Verhalten abbrechbarer Abläufe, die Verarbeitung von Unicode-Graphemen und nicht offensichtliche Invarianten im vorgeschriebenen Dokumentationsformat des Repositorys beschreiben. ## Regressionstests ergänzen, ohne die Abdeckung zu verringern - Von Agenten erzeugte Tests mit der im Repository anerkannten Agenten- und Modellkennzeichnung versehen. - Die Abdeckung niemals verringern, nur damit eine Änderung besteht. - Eine globale Initialisierung der Anwendung in Tests vermeiden, sofern das Verhalten nicht ausdrücklich einen prozessweiten Zustand erfordert. - Isolierte Vorbereitung, reproduzierbare Eingaben, virtuelle Zeit und beobachtbare Zusicherungen bevorzugen. - Jeden Test der zu seinem Zustandsmodell passenden Sammlung zuordnen, nicht lediglich der Datei mit dem ähnlichsten Namen. - Für den sichtbaren Fehler oder das sichtbare Verhalten eine Rückfallprüfung ergänzen und gegebenenfalls Fälle zu Anordnung und Ereignisreihenfolge einbeziehen. ## Das Logging des Repositorys nutzen und fragilen oder fremden Code nicht anfassen - Protokollierungs-, Testprotokollierungs- und Ablaufverfolgungsfunktionen des Repositorys verwenden; aus Bibliotheks- oder Testcode nicht unmittelbar in die Konsole schreiben. - Ein als empfindlich dokumentiertes Teilsystem nicht nebenbei zur Bereinigung umgestalten. - Bei der Umsetzung einer gezielten Funktion oder Fehlerbehebung keinen unbeteiligten Code ändern. - Keine neuen Warnungen des Compilers, Analysewerkzeugs, der Dokumentation oder der Tests einführen. - Vor der Fertigmeldung die Unterschiede erneut auf Formatierung, Begriffe, Testzuordnung und unbeabsichtigte Ausweitung des Umfangs prüfen. - Muss ein empfindlicher Bereich geändert werden, die Änderung auf das erforderliche Mindestmaß beschränken und sein eigenes Verhalten prüfen, bevor umfassendere Tests folgen.