Ein Monorepository mit mehreren Implementierungen ändern, ohne dass sie auseinanderlaufen

## Vor dem Ändern Aufbau und lokale Regeln des Monorepositorys lesen - Gliedere das Repository nach Produkt, Sprache, Funktionsgebiet, Bereich gemeinsamer Hilfsfunktionen, Prüfsammlung, Freigabewerkzeugen und Konfiguration. - Ermittle, welche Verzeichnisse zu den einzelnen Implementierungen gehören und welche übergeordneten Regeln für das gesamte Repository gelten. - Lies vor Änderungen in einem untergeordneten Bereich dessen örtlichen Agentenleitfaden, Mitwirkungsleitfaden und Konfiguration; örtliche Regeln dürfen die Grundlage genauer bestimmen, aber nicht abschwächen. - Wende sprachspezifische Bau-, Stil- und Prüfregeln nur auf Code an, der in dieser Sprache geschrieben ist. - Ermittle die Arbeitsbereichsdefinition, Stammskripte und produktspezifischen Anweisungen, bevor du Befehle oder Abhängigkeiten auswählst. ## Für Benutzer sichtbare Änderungen in jede Implementierung übernehmen - Behandle parallele Implementierungen desselben benutzersichtbaren Produkts als gleichwertige Wahrheitsquellen. - Übertrage jede benutzersichtbare Änderung möglichst im selben Änderungsantrag auf alle Implementierungen. - Benutzersichtbares Verhalten umfasst Schalter, Vorgabewerte, Umgebungsbehandlung, Fehlercodes und -meldungen, von Werkzeugen ausgewertete Protokolle, Datei- und Zustandsformate, Speicheranordnung und Hook-Semantik. - Interne Umstrukturierungen, nur eine Implementierung betreffende Leistungsarbeiten und implementierungsspezifische Prüfbereinigungen müssen nicht künstlich gespiegelt werden. - Wenn gleichwertige Arbeiten nicht sofort abgeschlossen werden können, benenne die genaue Gleichheitslücke, ihren Grund und die vor dem Zusammenführen erforderlichen Arbeiten. - Lass niemals zu, dass eine Implementierung zu einer nicht dokumentierten nachgeordneten Portierung einer anderen wird. ## Neu bauen, was die Tests ausführen, damit kein alter Code getestet wird - Installiere Abhängigkeiten und kompiliere über den dokumentierten Einrichtungsweg des Repositorys, bevor du Prüfergebnissen vertraust. - Kompiliere bei schnellen Arbeitsschritten nur das betroffene Paket, wenn dadurch dasselbe Artefakt entsteht, das die ausgewählten Prüfungen verwenden. - Ermittle, ob durchgängige Prüfungen Quellausgaben, Paketausgaben oder eine gebündelte ausführbare Datei ausführen. - Baue das Bündel nach jeder Änderung an einem enthaltenen Paket neu, wenn durchgängige Prüfungen das Bündel verwenden; andernfalls könnte die Prüfung veralteten Code ausführen. - Führe für jede geänderte Implementierung den passenden sprachspezifischen Bauvorgang aus. - Betrachte eine erfolgreiche Prüfung gegen veraltete erzeugte Ausgaben als ungültigen Nachweis. ## Nur Betroffenes testen und jedem Fehler nachgehen - Führe standardmäßig nicht die gesamte Prüfsammlung eines großen Repositorys aus. Beginne mit dem betroffenen Projekt, der Datei oder dem benannten Prüffall. - Erweitere den Prüfumfang nur, wenn Abhängigkeiten, gemeinsame Verträge oder beobachtete Fehler dies begründen. - Stimme Laufzeitumgebung, Bauartefakt und geprüfte Implementierung auf die zu bestätigende Behauptung ab. - Untersuche jeden Fehler, statt ihn ohne Nachweis als unbeteiligt oder bereits vorhanden einzustufen. - Wenn ein Fehler schon vor der Änderung bestand, ermittle seine Ursache und behebe ihn im erlaubten Umfang oder melde die konkrete Blockade; überspringe ihn niemals stillschweigend. - Halte den genauen Befehl, das betroffene Ziel und das Ergebnis fest, damit andere Mitwirkende den Nachweis reproduzieren können. ## Geänderten Code zuerst auf Sicherheit, dann auf Leistung durchsehen - Befolge den Prüfungsleitfaden des Repositorys und begrenze Feststellungen auf den von der Änderung betroffenen Code und seine unmittelbaren Folgen. - Prüfe zuerst Sicherheit und danach Leistung, sofern keine strengere Projektregel gilt. - Erläutere bei einer Sicherheitsfeststellung den erreichbaren Eingang, die Vertrauensgrenze, den Ausnutzungsweg und die Auswirkung. - Benenne bei einer Leistungsfeststellung den stark beanspruchten Pfad, die Häufigkeit, die Zuweisungs- oder E/A-Kosten und die wahrscheinliche Benutzerwirkung. - Prüfe als Teil der Abnahme die Tests, die Freigabeabsicht und die Gleichheit zwischen Implementierungen. - Erzeuge keine spekulativen Feststellungen, die sich nicht mit dem geänderten Verhalten verbinden lassen. ## Vor neuem Code oder neuen Abhängigkeiten nach Vorhandenem suchen - Durchsuche gemeinsame Pakete, Dateisystemhilfen, kryptografische Hilfsfunktionen, Texthilfen und benachbarte Fachmodule, bevor du nicht triviale Logik implementierst. - Verwende eine vorhandene exportierte Hilfsfunktion wieder, wenn sie das Verhalten bereits besitzt. - Wenn ähnliche Logik in einem Paket eingeschlossen ist, ziehe den gemeinsamen Vertrag an den engsten geeigneten gemeinsamen Ort heraus, statt die Logik zu kopieren. - Bevorzuge für allgemeine Funktionen eine gepflegte vorhandene Abhängigkeit, wenn sie geeignet, hinreichend leichtgewichtig und nach Repository-Richtlinie erlaubt ist. - Füge eine neue Abhängigkeit dem engsten Paket hinzu, das sie benötigt; verschiebe sie nur nach oben, wenn mehrere Pakete sie tatsächlich gemeinsam verwenden. - Füge keine Hüllen hinzu, die eine vorhandene Operation lediglich umbenennen oder weiterleiten, ohne einen Vertrag hinzuzufügen. ## Regeln für Commit-Nachrichten einhalten und Commit-Hooks nicht umgehen - Verwende die vorgeschriebene Commit-Nachrichtenkonvention des Repositorys und wähle den Änderungstyp, der die Benutzerwirkung widerspiegelt. - Bestätige vor einem Commit, dass die Repository-Hooks installiert und aktiv sind; in einer neuen Arbeitskopie sind sie möglicherweise noch nicht registriert. - Umgehe niemals eine fehlschlagende Commit-Schutzprüfung, deaktiviere nicht den Hook und füge keine Unterdrückungsdatei hinzu. Korrigiere die zugrunde liegende Nachricht oder Änderung. - Vermeide unqualifizierte rein numerische Vorgangsverweise, da die Hostingplattform sie mit dem falschen Repository verknüpfen kann; verwende einen qualifizierten Repository-Verweis oder eine absolute URL. - Setze benutzernamenähnliche Codebezeichner in eingebettete Codeformatierung oder entferne unnötige Erwähnungen, damit ein Commit keine unbeteiligten Personen benachrichtigt. - Verwende bei Aufzählungen Listennummern ohne Verweismarker. ## Bei Änderungen an veröffentlichten Paketen einen Freigabeeintrag ergänzen - Füge immer einen Eintrag zur Freigabeabsicht hinzu, wenn eine Änderung ein veröffentlichtes Paket betrifft. - Benenne jedes betroffene Paket und wähle die Versionsauswirkung aus Fehlerkorrektur, abwärtskompatibler Funktion oder inkompatibler Änderung. - Schreibe den Eintrag für Benutzer und halte ihn knapp; lege die Begründung der Implementierung in der Commit-Nachricht ab. - Nimm bei Änderungen an der Hauptimplementierung das primäre Befehlszeilenpaket auf, wenn die Repository-Richtlinie dies verlangt. - Benenne bei implementierungsspezifischen Änderungen nur die tatsächlich geänderten Produkte. Eine Gleichheitsänderung muss Pakete aus jeder betroffenen Implementierung benennen. - Beachte stabile und vorläufige Freigabewege, fest gekoppelte Versionsgruppen und das Verfahren zur Überführung in eine reguläre Freigabe. ## Kommentare nur für Gründe schreiben, die der Code nicht selbst zeigt - Bevorzuge Namen, Typen, Grenzen von Hilfsfunktionen und einen Kontrollfluss, durch die sich der Code selbst erklärt. - Füge keine Kommentare hinzu, die eine Operation wiederholen, die Dokumentation des Aufgerufenen duplizieren oder offensichtliche Syntax beschreiben. - Dokumentiere einen gemeinsamen Grund einmal beim gemeinsamen Eigentümer, statt ihn an jeder Aufrufstelle zu wiederholen. - Verwende Dokumentationskommentare für Vorbedingungen, Nachbedingungen, Randfälle und nicht offensichtliche Garantien. - Bewahre die Geschichte von Umstrukturierungen und Beschreibungen entfernter Entwürfe in der Versionsverwaltung und in Änderungsnachrichten, nicht in aktuellen Quelltextkommentaren. - Prüfe vor dem Hinzufügen von Erläuterungen, ob Umbenennen, Umstrukturieren oder Herausziehen die Aussage verlässlicher vermitteln würde. ## Formatierungs- und Fehlerbehandlungsregeln des Repositorys einhalten - Verwende das Formatierungswerkzeug und den sprachspezifischen Stilleitfaden des Repositorys; bewahre die bestehende Gruppierung und Reihenfolge der Importe. - Bevorzuge Funktionen gegenüber zustandsbehafteten Klassen, wenn der Codebestand dies vorsieht, und ersetze lange Parameterlisten durch ein typisiertes Optionsobjekt. - Verwende für benutzererreichbare Fehler stabile fachliche Fehlertypen, bewahre Fehlercodes, nimm den relevanten Zusammenhang auf und verschlucke niemals unerwartete Fehler. - Fange nur den erwarteten Fehlerzustand ab und verwende in virtualisierten Prüfumgebungen eine ausführungsbereichsübergreifend sichere Prüfung nativer Fehler. - Gib Funktionen Verbnamen, verwende Begriffe einheitlich und benenne ein Konzept überall um, wenn sich sein Vertrag ändert. - Bevorzuge für einfache Analysen einfache Zeichenkettenoperationen und für Grammatiken mit Rückverfolgung das vorhandene strukturierte Analyseprogramm. - Führe konfigurierbare Werte durch die Konfigurationsschicht, halte Befehlsverarbeitung unabhängig von der Darstellung und vermeide fest einprogrammierte Richtlinien. - Verwende asynchrone E/A, führe unabhängige Operationen gleichzeitig aus, warte erforderliche Abschlüsse ab und ziehe unveränderliche Arbeiten aus Schleifen heraus. ## Den Änderungsantrag bis zum Zusammenführen an die echten Änderungen anpassen - Eröffne einen Änderungsantrag mit der Repository-Vorlage, bewahre vorgeschriebene Abschnitte und entferne nur Inhalte, die die Vorlage als freiwillig kennzeichnet. - Halte Titel und Beschreibung nach jeder wesentlichen Aktualisierung mit den tatsächlichen Änderungen synchron. - Antworte in bearbeiteten Prüfungsgesprächen mit der Lösung und der zugehörigen Überarbeitung und markiere das Gespräch anschließend als erledigt. - Kennzeichne von Agenten erstellte, extern veröffentlichte Inhalte gemäß der Repository-Richtlinie, ohne vertraulichen Implementierungszusammenhang offenzulegen. - Verwende den vom Repository gebilligten Konfliktlösungsablauf, damit die Grundlage aktuell ist, erzeugte Sperrdaten deterministisch neu gebaut werden und die Zusammenführbarkeit geprüft wird. - Prüfe Konflikte in nicht erzeugten Inhalten manuell. Jede erzwungene Aktualisierung oder sonstige Umschreibung des Verlaufs im entfernten Repository erfordert ausdrückliche Genehmigung und ein geprüftes Ziel.