Code in einem großen Monorepo mit vielen Paketen ändern und testen

## Vor dem Bearbeiten Pakete und Einstiegspunkte finden - Ermitteln Sie den Aufbau des Arbeitsbereichs, veröffentlichte Pakete, native Komponenten, Testsammlungen, Beispiele, Dokumentation und Wartungsskripte. - Suchen Sie den Quellbaum des Hauptpakets, kompilierte Ausgaben, Befehlszeilen-Einstiegspunkte, Server-Einstiegspunkte und den Einstiegspunkt des Erstellungsvorgangs. - Verfolgen Sie den maßgeblichen Einstiegspunkt, bevor Sie Verhalten ändern; leiten Sie die Zuständigkeit nicht allein aus einem Dateinamen ab. - Lesen Sie vor der Bearbeitung einer verschachtelten Datei alle anwendbaren `README.md` vom Stammverzeichnis des Repositorys bis zum Zielverzeichnis. - Behandeln Sie erzeugte Ausgaben und Abhängigkeitsverzeichnisse ausschließlich als Suchbelege. Ändern Sie deren Quelle oder Generator, statt erzeugte Dateien direkt zu bearbeiten. ## Build-Ausgaben aktuell halten und einen gezielten oder vollständigen Build wählen - Führen Sie nach einem Zweigwechsel oder der Initialisierung eines Arbeitsbereichs mit unklarem Zustand den vollständigen Bootstrap-Erstellungsvorgang aus, damit die Ausgaben abhängiger Pakete aktuell sind. - Starten Sie bei wiederholter Arbeit am Quellcode oder an Integrationstests vor der Bearbeitung den fortlaufenden Erstellungsvorgang des Pakets, sofern er nicht bereits läuft. - Eine reine Dokumentationsänderung, eine schreibgeschützte Untersuchung oder eine reine CI-Analyse darf den fortlaufenden Modus auslassen; halten Sie den Grund jedoch fest. - Verwenden Sie den gezielten Paket-Erstellungsvorgang, wenn Änderungen innerhalb eines Pakets bleiben. Verwenden Sie den vollständigen Erstellungsvorgang, wenn die Arbeit mehrere Pakete betrifft oder nativen Code ändert. - Bevorzugen Sie bei Typfehlern die spezielle Typprüfung gegenüber einem vollständigen Erstellungsvorgang, wenn sie gleichwertige Nachweise liefert. - Beenden Sie nach Abschluss der Aufgabe alle von Ihnen gestarteten fortlaufenden Prozesse. ## Tests passend zum Entwicklungs- oder Produktionsmodus wählen - Wählen Sie den Testbefehl, der exakt zum Entwicklungs- oder Produktionsverhalten und zum vorgesehenen Bündelungswerkzeug oder zur vorgesehenen Laufzeitimplementierung passt. - Erstellen Sie den betroffenen Quellcode vor Integrationstests neu; veraltete kompilierte Ausgaben machen das Ergebnis ungültig. - Führen Sie zuerst die engste einschlägige Testdatei oder das engste Namensmuster aus und erweitern Sie den Umfang nur, wenn der Fehler oder die Änderungsfläche dies erfordert. - Reproduzieren Sie CI mit demselben Befehl, Modus, denselben Funktionsschaltern und Umgebungsvariablennamen. Kleine Modusunterschiede können die Auflösung und Momentaufnahmen verändern. - Ersetzen Sie einen Integrationstest nicht durch einen bequemeren Modultest, wenn die Aussage Paketauflösung, Bündelung, Startvorgang oder Browserverhalten umfasst. - Wenn Funktionsschalter ein Verhalten implizit aktivieren, testen Sie die reguläre Testsammlung mit diesem Schalter, statt sich nur auf ältere spezielle Testsammlungen zu verlassen. ## Tests schreiben, die auf Bedingungen statt auf feste Wartezeiten warten - Verwenden Sie den Testgenerator des Repositorys einschließlich seiner nicht interaktiven Argumente, damit Testvorgaben und die Konfiguration des Testgerüsts den örtlichen Konventionen folgen. - Bevorzugen Sie bedingungsbasierte Wiederholungshelfer mit Zusicherungen gegenüber festen Wartezeiten. Feste Verzögerungen sind langsam und bleiben anfällig für Wettlaufsituationen. - Ersetzen Sie veraltete Abfragehelfer durch das unterstützte Muster aus Wiederholung und Zusicherung. - Bevorzugen Sie echte Verzeichnisse mit Testdateien gegenüber großen eingebetteten Dateizuordnungen, damit Tests wirklichen Projekten ähneln und wartbar bleiben. - Führen Sie bei modusspezifischen Tests die Modusschranke vor dem manuellen Start eines Servers aus, wenn das Testgerüst einen verzögerten Start verlangt. - Steuern Sie Vorabruf und Navigationszustand innerhalb der Synchronisationsgrenze des Tests; vermeiden Sie Verlaufsaktionen, die zwischengespeicherte Zustände wiederherstellen und unkontrollierte Arbeit auslösen. ## Test- und Build-Ausgaben speichern, statt alles neu auszuführen - Erfassen Sie die vollständige Ausgabe eines Tests oder Erstellungsvorgangs einmal und durchsuchen und fassen Sie anschließend die gespeicherte Ausgabe zusammen, statt dieselbe Testsammlung mit anderen Filtern erneut auszuführen. - Suchen Sie bei Dateien mit mehr als etwa 500 Zeilen zuerst nach maßgeblichen Symbolen und lesen Sie nur die umliegenden Bereiche. - Durchsuchen Sie erzeugte Verzeichnisse nur, wenn dies zur Bestätigung des ausgegebenen Verhaltens nötig ist; verwenden Sie sie nicht als Hauptquelle. - Fassen Sie zusammengehörige Bearbeitungen vor dem nächsten Erstellungsvorgang zusammen und verwenden Sie die schnellste Prüfung, die die aktuelle Hypothese belegt. - Speichern Sie Antworten zum entfernten Status während einer Untersuchung zwischen und analysieren Sie die gespeicherte Antwort aus mehreren Blickwinkeln, statt sie wiederholt abzurufen. - Bewahren Sie die genaue Fehlerausgabe, den Befehl, den Modus und die Umgebung als Nachweis für den nächsten Diagnoseschritt auf. ## CI-Fehler nachstellen und vor Review-Kommentaren beheben - Verwenden Sie das Statusanalysewerkzeug des Repositorys, sofern eines vorhanden ist, und stellen Sie fest, ob der aktuelle Zweig oder eine ausdrücklich angegebene Änderungsanfrage untersucht wird. - Beheben Sie blockierende Fehler in dieser Reihenfolge, sofern die Nachweise nichts anderes verlangen: Erstellung, Formatierung oder statische Stilprüfung, Typen und anschließend Tests. - Behandeln Sie Fehler als real, bis das Gegenteil belegt ist. Bekanntes unzuverlässiges Verhalten ist Untersuchungskontext und keine Erlaubnis, einen Fehler zu verwerfen. - Reproduzieren Sie mit demselben CI-Modus und denselben Umgebungsschaltern, besonders wenn unterschiedliche Bündelungswerkzeuge oder Laufzeitpfade verfügbar sind. - Führen Sie bei Fehlern der Modulauflösung oder des Erstellungsgraphen den regulären modusspezifischen Integrationsbefehl aus, damit der echte Paketgraph ausgeübt wird. - Trennen Sie CI-Fehler von Prüfkommentaren, lösen Sie zuerst die blockierenden Ausführungsnachweise und bewahren Sie eine knappe Aufzeichnung des Reproduzierten auf. ## Feature-Flags durch Build- und Laufzeitcode durchreichen - Fügen Sie einen neuen Funktionsschalter seinem öffentlichen Typ, dem Validierungsschema und der Einspeisestelle zur Erstellungszeit hinzu, wenn vom Benutzer gebündelter Code ihn verwendet. - Wenn vorkompilierter Laufzeitcode den Schalter verwendet, leiten Sie den Laufzeitwert zusätzlich durch jeden maßgeblichen Server- oder Arbeitsprozesspfad. - Gehen Sie nicht davon aus, dass die Einspeisung zur Erstellungszeit für Benutzercode die Interna der vorkompilierten Laufzeit steuert. - Halten Sie bedingte Modulladevorgänge innerhalb von `if`- / `else`-Zweigen zur Kompilierzeit, damit die Entfernung ungenutzten Codes unerreichbare Abhängigkeiten beseitigen kann. - Erzwingen Sie in eingeschränkten Laufzeitumgebungen für Schalter, die nicht unterstützte Plattformimporte absichern, den Wert `false`. - Belassen Sie laufzeitspezifische Importe in ihrem vorgesehenen Einstiegsmodul und stellen Sie das benötigte Verhalten über die öffentliche Schnittstellenfassade dieses Moduls bereit. - Verwenden Sie ein eigenes Laufzeitsignal, um einen aktiven Entwicklungsserver von einer zur Fehlersuche erstellten Fassung zu unterscheiden; eine allgemeine Umgebungskennzeichnung kann beides beschreiben. - Kennzeichnen Sie jeden neuen, nicht standardisierten eingehenden Anfragekopf zur Sicherheitsprüfung, sofern die Eingangsschicht ihn nicht entfernt oder authentifiziert. ## Geheimwerte aus Protokollen heraushalten und bei fehlgeschlagener Authentifizierung anhalten - Behandeln Sie Werte von Umgebungsvariablen als vertraulich, sofern es sich nicht um dokumentierte Schalter für den Testmodus handelt. - Geben Sie niemals Token, Schlüssel, Cookies oder Geheimwerte in gemeinsamen Protokollen, Prüftexten oder Beispielen aus, fügen Sie sie dort nicht ein, übernehmen Sie sie nicht in einen Commit und legen Sie sie dort nicht ab. - Übernehmen Sie Namen und Modi der CI-Variablen, ohne ihre Werte direkt einzubetten. Fehlt ein erforderliches Geheimnis, halten Sie an und fordern Sie es über den genehmigten Kanal an. - Verwenden Sie bei der Dokumentation der Einrichtung Platzhalter und übernehmen Sie lokale Geheimnisdateien niemals in einen Commit. - Scheitert die Authentifizierung der Versionsverwaltung, weil ein Signaturagent, Schlüsselanbieter oder eine hardwaregestützte Berechtigung nicht verfügbar ist, halten Sie an und bitten Sie den Benutzer, sie zu entsperren. - Ändern Sie ohne ausdrückliche Genehmigung weder entfernte Protokolle noch Adressen, wiederholen Sie den fehlgeschlagenen Vorgang nicht und versuchen Sie keine alternative Umgehung der Authentifizierung. ## Vor Änderungsanfragen oder Kommentaren die Berechtigung prüfen - Stellen Sie vor dem Erstellen oder Bearbeiten einer Änderungsanfrage, eines Vorgangs, einer Diskussion oder eines Kommentars in einem entfernten Repository fest, ob der Beitrag aus einem internen Zweig oder einem externen Fork stammt. - Prüfen Sie die Beitragsrichtlinie des Repositorys und die Berechtigung des Benutzers, bevor Sie in seinem Namen schreiben. - Reicht die Berechtigung nicht aus, geben Sie sich nicht als Verantwortlicher für die Wartung aus und veröffentlichen Sie dort keine vollständigen Inhalte. Bieten Sie technische Fakten an, prüfen Sie vom Benutzer verfassten Text und verweisen Sie auf den vom Benutzer kontrollierten Einreichungsweg. - Wenden Sie dokumentierte Ausnahmen eng begrenzt und erst nach Prüfung ihrer Bedingungen an. - Belassen Sie neu erstellte Änderungsanfragen im Entwurfszustand, sofern der Benutzer nicht ausdrücklich entscheidet, dass sie zur Prüfung bereit sind. - Schreibvorgänge in entfernten Systemen benötigen einen ausdrücklichen Umfang; lokale Analyse und Reproduktion bedeuten keine Erlaubnis zur Veröffentlichung. ## Arbeit in kleine Schritte teilen und jeden Schritt prüfen - Zerlegen Sie eine große Aufgabe in kleine Schritte, deren Ergebnisse unabhängig geprüft werden können. - Verifizieren Sie jeden Schritt vor dem nächsten mit der seinem Risiko entsprechenden Methode: Sichtprüfung, Formatierung, statische Stilprüfung, Typprüfung, Modultests, Integrationstests, Erstellung oder Laufzeitbeobachtung. - Fragen Sie bei unklarer korrekter Verifikationsmethode nach, bevor Sie den Schritt als abgeschlossen bezeichnen. - Führen Sie vor einem Commit auf den geänderten Dateien dieselbe Formatierer- und Stilprüferkonfiguration aus, die die Commit-Prüfroutine des Repositorys verwendet. - Prüfen Sie den abschließenden Unterschied auf sachfremde Bearbeitungen, erzeugtes Rauschen, geheimes Material sowie fehlende Tests oder Dokumentation. - Melden Sie keinen Abschluss, ohne die Nachweise zu benennen, die das geänderte Verhalten stützen. ## Veraltete native Binärdateien und abweichende Snapshots erkennen - Die Suche in Quellzuordnungen kann einen ausdrücklichen Laufzeitschalter erfordern, und Quellpfade können sich zwischen Compilern unterscheiden; testen Sie die bekannten Pfadformen. - Berücksichtigen Sie beim Vergleich von Stapelspuren aus Tests und Produktion das aktuelle Arbeitsverzeichnis. - Vermuten Sie nach Zweigwechseln veraltete native Binärdateien, wenn das Verhalten dem Quellcode widerspricht; aktualisieren Sie das von der Abhängigkeitsverwaltung verwaltete Artefakt über den genehmigten Bootstrap-Pfad. - Entfernen Sie bei einem internen Compilerfehler nur den betroffenen Zwischenspeicher für schrittweise Kompilierung und wiederholen Sie den Vorgang genau einmal, bevor Sie ihn eskalieren. - Verwenden Sie den offiziellen Formatierer für Code in einer nativen Sprache und bevorzugen Sie Importe mit Bezug zum Repository-Stamm, außer in eng begrenzten eingebetteten Testmodulen. - Ausgaben von Momentaufnahmen können je nach Schaltern und Laufzeitimplementierung variieren; aktualisieren Sie Momentaufnahmen daher nur in exakt der Umgebung des Ziel-CI-Auftrags. - Zählen Sie in Dokumentations-Codeblöcken nach Bearbeitungen die dargestellten Zeilen erneut und bestätigen Sie, dass jede Hervorhebung auf die beabsichtigte Anweisung zeigt.