Ein plattformübergreifendes Befehlszeilenprogramm im gemeinsamen Arbeitsbaum entwickeln, ohne fremde Arbeit zu zerstören

## Nur im aktuellen Arbeitsbaum suchen und bearbeiten Wenn die Entwicklung Arbeitsbäume verwendet, ist das aktuelle Arbeitsverzeichnis das vollständige Repository des aktiven Zweigs. Suchen, lesen, erstellen, testen und bearbeiten Sie nur innerhalb dieses Stammverzeichnisses. - Verwenden Sie relative Pfade oder aufgelöste Pfade unterhalb des aktuellen Stammverzeichnisses. - Nehmen Sie nicht an, dass ein übergeordnetes Verzeichnis das Repository ist. - Durchsuchen Sie keine benachbarten Arbeitsbäume nach Implementierungen oder Konfigurationen. - Lehnen Sie fest codierte Pfade zum Stammverzeichnis eines Entwicklers ab. - Lösen Sie Pfade zu Testdaten und Quelltext vom aktiven Stammverzeichnis aus auf. Das Verlassen des Arbeitsbaums kann veralteten Quelltext eines anderen Zweigs in Analysen und Änderungen einmischen. ## Änderungen anderer Sitzungen nicht zurücksetzen oder löschen Gehen Sie davon aus, dass unbekannte Dateien und Bearbeitungen zu einer anderen aktiven Sitzung gehören können. Sie dürfen Arbeit niemals allein deshalb löschen, zurücksetzen, verwerfen oder überschreiben, weil sie außerhalb der aktuellen Aufgabe liegt. - Bewahren Sie Dateien, die Sie nicht erstellt haben. - Fragen Sie nach, bevor Sie nicht nachverfolgte Dateien entfernen. - Führen Sie ohne ausdrückliche Genehmigung keine Vorgänge mit `reset`, Verwerfen durch `checkout`, `clean` oder Löschen eines `stash` aus. - Wenn automatische Prüfschritte wegen unberührter Dateien fehlschlagen, melden Sie den Konflikt, statt diese Dateien zu ändern. - Begrenzen Sie Änderungen auf den angeforderten Umfang und prüfen Sie den abschließenden Änderungsvergleich. Behandeln Sie den Zustand eines gemeinsam genutzten Arbeitsbaums als Benutzerdaten, deren Eigentümerschaft vor einer zerstörerischen Aktion geklärt werden muss. ## Befehle über ein Register statt über verstreute Bedingungen ergänzen Verwenden Sie ein Register, um Befehle, Anbieter und Integrationen erweiterbar zu machen. Eine neue Implementierung sollte eine stabile Schnittstelle erfüllen und sich über einen einzigen maßgeblichen Pfad registrieren, statt in der gesamten Anwendung Bedingungen hinzuzufügen. - Definieren Sie Schnittstellen für das wesentliche Verhalten. - Übergeben Sie Abhängigkeiten über Konstruktoren oder Felder. - Erzeugen Sie Testdoppel mit dem vom Repository unterstützten Erzeugungswerkzeug. - Verwenden Sie funktionale Optionen für erweiterbare Konfigurationen mit Standardwerten. - Halten Sie eine Befehlsimplementierung pro Datei mit klar abgegrenzter Aufgabe. - Fügen Sie zweckgebundene Pakete hinzu, statt ein allgemeines Hilfspaket auszuweiten. Durchsuchen Sie bestehende Befehls-, Ausführungs- und Paketschichten, bevor Sie parallele Logik einführen. ## Den Kontext nur für Abbruch und Fristen nutzen und Schalter über einen einzigen Parser leiten Verwenden Sie Anforderungskontext nur für Abbruch, Fristen und wenige anforderungsbezogene Werte. Übergeben Sie ihn als ersten Parameter, wenn eine Funktion ihn annimmt. Verwenden Sie Kontext nicht, um Konfiguration, Abhängigkeiten oder gewöhnliche Parameter zu verbergen. Modellieren Sie Konfiguration als deterministische Verarbeitungskette: 1. Konfigurationsquellen laden; 2. Importe und Vererbung verarbeiten; 3. die Rangfolge von Befehlsschaltern über Umgebung und Dateien bis zu Standardwerten anwenden; 4. unterstützte Vorlagen darstellen; 5. die wirksame Konfiguration erzeugen. Leiten Sie Schalter und Umgebungsbindungen durch das einheitliche Analyseprogramm. Aktualisieren Sie beim Hinzufügen einer Option jedes zuständige Schema und umgehen Sie niemals die zentrale Bindungsschicht. ## Weiterleitbare Daten und Meldungen für Menschen in getrennte Ausgabeströme schreiben Schreiben Sie weiterleitbare Ergebnisse nur in den Datenstrom. Schreiben Sie Eingabeaufforderungen, Fortschritt, Warnungen und formatierte menschliche Meldungen in den Oberflächenstrom. Reservieren Sie strukturierte Protokollierung für Systemereignisse statt für benutzerbezogene Ausgabe. - Verwenden Sie gemeinsame Ein-/Ausgabeabstraktionen statt direkter Ausgabe. - Lassen Sie die Benutzeroberflächenschicht Farben, Symbole, Markdown, Terminalbreite und Funktionserkennung verwalten. - Vereinfachen Sie die Darstellung automatisch, wenn das Terminal keine Gestaltung unterstützt oder die Ausführung in der kontinuierlichen Integration erfolgt. - Halten Sie strukturierte Daten gültig, wenn die menschenlesbare Formatierung abgeschaltet ist. - Wenden Sie die Maskierung von Geheimnissen einheitlich an und erfassen Sie keine Benutzerdaten in der Telemetrie. Test- oder Aufzeichnungsschalter dürfen Terminaleigenschaften erzwingen, aber die Standardeinstellungen für den Produktivbetrieb sollten weiterhin die Umgebung berücksichtigen. ## Funktionen klein halten und Fehler mit festen Kategorien umhüllen Halten Sie Dateien und Funktionen fokussiert. Extrahieren Sie benannte Schritte aus einer hochkomplexen Ablaufsteuerung, damit die oberste Funktion wie eine flache Verarbeitungskette lesbar ist. - Verwenden Sie die Standardformatierung, Importgruppierung, Aliasse und Kommentarsatzzeichen des Repositorys. - Bewahren Sie hilfreiche Kommentare und aktualisieren Sie sie bei Verhaltensänderungen. - Wenden Sie die standardmäßige Leistungserfassung auf bedeutsame öffentliche Operationen an. - Nehmen Sie einfache Zugriffsfunktionen, Konstruktoren, reine Suchvorgänge und einfache Delegationen aus, wenn die Richtlinie dies erlaubt. - Kapseln Sie Fehler mit stabilen Kategorien und bewahren Sie ihre Ursachen. - Verbinden Sie unabhängige Fehlschläge, ohne eine der Fehlerketten zu verlieren. - Prüfen Sie gekapselte Fehler durch semantischen Abgleich statt durch Zeichenfolgenvergleich. Verwenden Sie aussagekräftige Fehlererzeuger, wenn Benutzer Hinweise, Kontext oder Beendigungsbedeutungen benötigen. ## Verhalten mit Mocks und Tests prüfen, die wirklich fehlschlagen können Bevorzugen Sie schnelle Komponententests mit erzeugten Testdoppeln für isoliertes Verhalten. Ergänzen Sie anschließend Integrations- oder Abnahmetests dort, wo das öffentliche Befehlsverhalten echte Grenzen überschreitet. - Verwenden Sie tabellengesteuerte Fälle für Eingabe- und Fehlerabdeckung. - Testen Sie Verhalten statt interner Implementierung. - Entfernen Sie Platzhalterimplementierungen, tautologische Tests und dauerhaft übersprungene Tests. - Verändern Sie bei zusammengeführten Sammlungen Ergebnis und Quelle in getrennten Prüfungen, um die beidseitige Isolation nachzuweisen. - Prüfen Sie bei Slice-Ergebnissen neben der Länge auch repräsentative Inhalte. - Ergänzen Sie Negativtests, die nachweisen, dass eine Wiederherstellung ohne ihre Bedingung nicht ausgelöst wird. - Verwenden Sie semantischen Fehlerabgleich für gekapselte Fehlschläge. Testabdeckung ist nur dann ein Nachweis, wenn Prüfbehauptungen am geschützten Verhalten scheitern können. ## Tests schreiben, die auf allen Systemen laufen und bei fehlender Vorbereitung klar fehlschlagen Tests müssen auf unterstützten Desktop- und Serverplattformen laufen, ohne eine Shell, ein Pfadtrennzeichen oder ein plattformspezifisches Hilfsprogramm vorauszusetzen. - Erstellen Sie Pfade aus einzelnen Bestandteilen mit der Standardpfadbibliothek. - Vereinheitlichen Sie Trennzeichen nur für übertragbare Endungs- oder Darstellungsvergleiche. - Verwenden Sie statt plattformspezifischer Befehle das Testprogramm oder ein eingeschleustes Ausführungsprogramm. - Fügen Sie Unterprozessschranken in einen bestehenden Testeinstieg ein, statt einen doppelten Einstieg zu definieren. - Lösen Sie Stammverzeichnisse der Testdaten vor Durchlauf oder Zählung in absolute Pfade auf. - Lassen Sie Vorbedingungs- und Testdatenzählerprüfungen eindeutig fehlschlagen, wenn die Einrichtung fehlt. - Ergänzen Sie Kompilierungswächter für Schemafelder, deren Umbenennung den Test scheitern lassen muss. Prüfen Sie die implizite Umgebungsweitergabe in einem ausdrücklichen Vorbedingungs-Untertest, bevor Sie davon abhängiges Unterprozessverhalten testen. ## Momentaufnahmen über die Testwerkzeuge neu erzeugen, statt sie von Hand zu ändern Referenz-Momentaufnahmen enthalten unsichtbare Formatierung, Terminalbreite, Gestaltung und umgebungsabhängige Ausgabe. Bearbeiten Sie sie niemals manuell. - Erstellen Sie Momentaufnahmen über den unterstützten Testschalter oder Erzeuger neu. - Prüfen Sie den daraus entstehenden Änderungsvergleich, bevor Sie ihn annehmen. - Leiten Sie Momentaufnahme- oder Terminaltests nicht durch eine Verarbeitungskette, da Umleitung die Funktionserkennung verändern kann. - Erstellen Sie zugehörige Aufzeichnungen gemeinsam neu, wenn sich Befehlshilfe oder Ausgabe ändern. - Prüfen Sie Aufzeichnungen auf Befehlsfehler, fehlende Verweise und offengelegte maschinenspezifische Pfade. - Ändern Sie geschützte Testdaten oder Prüfressourcen nicht ohne ausdrücklichen Umfang. Erzeugte Ausgabe muss über ihre zuständige Quelle und den maßgeblichen Arbeitsablauf geändert werden. ## Jeden neuen Befehl dokumentieren und aufgeschobene Arbeit als Ticket erfassen Jeder neue Befehl, Schalter, Parameter oder jede neue Konfigurationsoberfläche benötigt Benutzerdokumentation mit den vom Repository geforderten Metadaten, Verwendungshinweisen, Beispielen, Argumenten, Schaltern und visuellen Nachweisen. - Prüfen Sie die erklärte Seitenkennung, statt eine URL aus dem Dateinamen zu erraten. - Bauen Sie die Dokumentationswebsite nach Änderungen und prüfen Sie Verweise, Bilder und Komponenten. - Erstellen Sie visuelle Aufnahmen neu, wenn sich Befehlsverhalten, Hilfe oder Ausgabe ändern, nicht bei reinen Textänderungen. - Legen Sie Anforderungsdokumente am vorgesehenen Ort und nach der vorgesehenen Namenskonvention ab. - Erstellen Sie bei aufgeschobener Arbeit vor dem Zusammenführen einen nachverfolgten Vorgang und verknüpfen Sie seine Kennung. - Stimmen Sie Veröffentlichungshinweise, Entwicklungsplandaten und Kennzeichnungen auf die Änderungsklasse ab. Dokumentation ist unvollständig, wenn sie nicht nachverfolgte Folgearbeit verspricht. ## Begutachtungen aktualisieren, ohne Hooks zu umgehen oder zerstörerische Git-Befehle zu nutzen Verwenden Sie den Begutachtungsablauf des Repositorys und begrenzen Sie wiederkehrende Wartungsautomatisierung auf die Sitzung, sofern kein dauerhafter Dienst ausdrücklich genehmigt wurde. - Führen Sie `rebase` oder Aktualisierung nur über den genehmigten Zweigablauf aus. - Prüfen Sie die kontinuierliche Integration und bearbeiten Sie ungelöste Diskussionsfäden der Begutachtung. - Antworten Sie im ursprünglichen Diskussionsfaden der Begutachtung und prüfen Sie die Verknüpfung. - Führen Sie vor der Aktualisierung der Begutachtung statische Analyse und Testabdeckung im Umfang des Änderungssatzes aus. - Umgehen Sie keine automatischen Prüfschritte und verwenden Sie keine Schalter zum Überspringen der Prüfung. - Übernehmen Sie keine Entwurfsnotizen, Recherchen oder ungelösten Platzhalter in einen Commit. Führen Sie niemals zerstörerische Git-Befehle aus und entfernen Sie keine Arbeit einer anderen Sitzung, ohne ausdrücklich bestätigen zu lassen, was verloren geht. ## Fehler zuerst mit einem Test nachstellen und fehlgeschlagene Prüfungen an der Ursache beheben Schreiben Sie bei einem Fehler zuerst einen reproduzierenden Test, beobachten Sie den Fehlschlag, setzen Sie die kleinste Korrektur um und prüfen Sie auf Regressionen. Bestätigen Sie vor dem Abschluss: - Das Projekt lässt sich mit der festgelegten Werkzeugkette kompilieren. - Geänderte Dateien bestehen das maßgebliche Formatierungswerkzeug und die statische Prüfung. - Kurze Tests bestehen, und vollständige oder Abnahmetests laufen, wenn der betroffene Pfad sie erfordert. - Die Testabdeckung erfüllt die vorgeschriebene Schwelle ohne substanzlose Prüfbehauptungen. - Erzeugte Testdoppel, Schemata, Momentaufnahmen, Dokumente und visuelle Aufnahmen sind aktuell. - Komplexitäts- und Dateigrößenbegrenzungen bleiben eingehalten. - Plattformübergreifende Pfade und Unterprozesstests sind übertragbar. - Kein Geheimnis, keine Benutzerdaten und keine sachfremde Arbeit sind in den Änderungsvergleich gelangt. Beheben Sie die Ursache jeder fehlgeschlagenen Schranke, statt die Schranke abzuschwächen.