Code in großen Repositorys mit mehreren Sprachen ändern und nur Nötiges bauen und testen

## Erst recherchieren und planen, dann die kleinste Änderung bauen und testen Verwenden Sie für jede Änderung eine wiederholbare Abfolge: 1. Untersuchen Sie den Auftrag, den relevanten Quelltext, Schnittstellen zu Abhängigkeiten, vorhandene Prüfungen und bekannte Fehlerbilder. 2. Erstellen Sie einen groben Umsetzungsplan und prüfen Sie dessen Annahmen, Grenzfälle und betriebliche Risiken kritisch. 3. Untersuchen Sie ähnlichen Quelltext, um Aufbau, Benennung, Fehlerbehandlung und Prüfmuster des Quellcodebestands zu verstehen. 4. Stellen Sie den Plan nur vor, wenn der Benutzer darum bittet; setzen Sie die Umsetzung andernfalls fort. 5. Setzen Sie die kleinste in sich geschlossene Änderung um, die den Auftrag erfüllt. 6. Prüfen Sie das Ergebnis auf korrekte Programmierschnittstellen, Klarheit, Leistung, Lesbarkeit und unbeabsichtigte Ausweitung des Umfangs. 7. Führen Sie Formatierung, gezielte Erstellungsläufe und einschlägige Prüfungen aus und überarbeiten Sie Fehler anschließend schrittweise. Behandeln Sie einen fertigen Entwurf nicht als Abschluss. Eine Änderung ist erst bereit, nachdem die Umsetzung und das unmittelbar betroffene Verhalten geprüft und validiert wurden. ## Vor dem Bearbeiten dem Muster des ähnlichsten Codes folgen Lesen Sie die übergeordneten Beitragsrichtlinien des Quellcodebestands und alle pfadspezifischen Anweisungen für die zu ändernden Dateien. Suchen Sie das nächstgelegene funktionierende Vorbild, etwa eine verwandte Klasse, ein benachbartes Paket, eine ähnliche Prüfung oder einen zugehörigen Arbeitsablauf, und folgen Sie dessen bestehender Struktur, sofern die Aufgabe keine bewusste Abweichung verlangt. Überprüfen Sie Schnittstellen von Abhängigkeiten und Grenzfälle anhand maßgeblicher Schnittstellen oder vorhandener Verwendungen. Suchen Sie bestehende Prüfungen, bevor Sie neue erstellen, und binden Sie zusätzliche Abdeckung in die vorhandenen Prüfsysteme ein, statt eine parallele Prüfinfrastruktur zu erfinden. Beschränken Sie die Untersuchung auf das angeforderte Verhalten. Verbinden Sie die Änderung nicht mit sachfremden Umbenennungen, Verzeichnisverschiebungen, großflächigen reinen Formatierungsänderungen oder architektonischen Aufräumarbeiten. ## Vor dem Testen verfügbare Werkzeuge und Hardware feststellen Stellen Sie vor der Wahl von Befehlen fest, welche Compiler, Laufzeitumgebungen, Erstellungswerkzeuge, isolierten Umgebungen, Beschleuniger und Zugangsdaten tatsächlich verfügbar sind. Unterscheiden Sie eine fehlende Möglichkeit von einem Produktfehler: Ein fehlendes Gerät, ein nicht unterstütztes Laufzeitsystem für isolierte Umgebungen oder eine fehlende Werkzeugkette beweist keinen Fehler im Quelltext. Verwenden Sie die standardisierte isolierte Entwicklungsumgebung des Quellcodebestands, wenn sie unterstützt wird und für die Reproduzierbarkeit erforderlich ist. Führen Sie andernfalls alle in der aktuellen Umgebung möglichen, aussagekräftigen Prüfungen aus und bestimmen Sie den kleinsten verbleibenden Befehl, der einen anderen Rechner oder eine Benutzerhandlung erfordert. Behaupten Sie niemals, dass eine nicht verfügbare Prüfung bestanden wurde. Melden Sie die genaue Einschränkung, die ohne diese Prüfung abgeschlossene Validierung und das verbleibende Risiko. ## Nur die Teile bauen und testen, die die Änderung betrifft Bevorzugen Sie die vom Quellcodebestand bereitgestellten Voreinstellungen und Hilfsskripte gegenüber handgefertigten Befehlsfolgen. Ermitteln Sie die unterstützten Voreinstellungen, wählen Sie die zum geänderten Baustein und zur Sprachstufe passende aus und beschränken Sie sich auf die einschlägigen Erstellungsziele, Modultests, Integrationstests oder Compilerprüfungen. Nutzen Sie Abhängigkeitsinformationen, um nachgelagerte Bausteine einzubeziehen, die von einer gemeinsamen oder stark abhängigen Änderung betroffen sind. Vermeiden Sie bei einer örtlich begrenzten Änderung die Neuerstellung sachfremder Pakete. Führen Sie vollständige Erstellungsläufe und vollständige Prüfsammlungen nur bei bereichsübergreifenden Änderungen, Freigabestufen oder ausdrücklichen Vorgaben des Quellcodebestands aus. Halten Sie fest, warum der gewählte Umfang ausreicht. Eine begrenzte Prüfung ist nur wertvoll, wenn ihr Zusammenhang mit der Änderung klar ist. ## Jede Sprache und Hardware-Architektur auf ihre eigene Art testen Behandeln Sie jede Sprache oder Paketschicht gemäß ihrer eigenen Schnittstelle. Systemnahe Bibliotheken können Einstellungen für Compiler, Sprachstandard und Architektur erfordern, während Pakete für Skriptsprachen Laufzeitversionen, zusätzliche Abhängigkeiten und paketspezifische Prüfeinstiege benötigen können. Übertragen Sie keine Parameter eines Ökosystems auf ein anderes. Unterscheiden Sie bei architekturabhängigem Quelltext zwischen Prüfungen nur auf dem Wirtsystem, reinen Übersetzungsprüfungen, Simulatoren oder virtuellen Zielplattformen und Prüfungen, die echte Hardware benötigen. Wählen Sie repräsentative Architekturen anhand des geänderten Verhaltens und des unterstützten Kompatibilitätsbereichs, statt standardmäßig jede Variante zu übersetzen. Untersuchen Sie bei Änderungen an einem gemeinsamen Baustein den Abhängigkeitsgraphen und validieren Sie die abhängigen Komponenten, bei denen Kompatibilitätsrückschritte am ehesten sichtbar werden. ## Günstige Prüfungen zuerst und langsame Builds nicht vorschnell abbrechen Gehen Sie davon aus, dass große Erstellungsläufe, erzeugte Prüfmatrizen und hardwarenahe Prüfsammlungen beträchtliche Zeit benötigen können. Setzen Sie realistische Zeitlimits, verwenden Sie unterstützte Zwischenspeicher, begrenzen Sie Architekturen und Ziele während der Überarbeitung und erweitern Sie die Abdeckung nur, wenn Risiko oder Freigabestufe den Aufwand rechtfertigen. Eine lange Laufzeit allein ist kein Beleg für einen Stillstand. Brechen Sie eine laufende Erstellung oder Prüfung nicht nur deshalb ab, weil sie langsam ist; halten Sie sie nur bei einem konkreten Fehlernachweis, einer ausdrücklichen betrieblichen Grenze oder einer Benutzeranweisung an. Staffeln Sie die Validierung so, dass kostengünstige Rückmeldungen zuerst eintreffen: Formatierung und statische Prüfungen, gezielte Übersetzung, auf dem Wirtsystem ausführbare Prüfungen und anschließend spezialisierte oder hardwareabhängige Prüfsammlungen. Bewahren Sie die abschließend geforderte Abdeckung, auch wenn frühe Überarbeitungen eine kleinere Teilmenge verwenden. ## CI beim Iterieren begrenzen, vor dem Merge aber vollständig laufen lassen Verwenden Sie Änderungserkennung und Auftragsmatrizen, um die für betroffene Bausteine einschlägigen Aufträge auszuführen. Zeitweilige Übersteuerungsmatrizen oder Auslassungsregeln können den Aufwand früher Überarbeitungen senken, besonders bei Infrastrukturänderungen oder stark abhängigen Bereichen, müssen aber sichtbar und prüfbar bleiben. Behandeln Sie eine verringerte Prüfungsabdeckung der kontinuierlichen Integration als Zusammenführungssperre. Stellen Sie vor dem Zusammenführen die vorgeschriebene vollständige Konfiguration wieder her und erzielen Sie einen erfolgreichen Lauf ohne zeitweilige Übersteuerungen oder Auslassungsregeln. Entfernen Sie ohne ausdrückliche Anweisung weder die Übersteuerung eines anderen Mitwirkenden noch verändern Sie deren Umfang. Halten Sie die Übersteuerungskonfiguration strukturell gültig, wenn die Ablaufsteuerung einen leeren Wert statt ihrer Entfernung erwartet. Bestätigen Sie, dass die Ergebniszusammenfassung in einem sicheren Fehlerzustand endet, wenn vorgeschriebene Aufträge fehlschlagen oder die verringerte Abdeckung aktiv bleibt. ## Formatter und Linter ausführen und nicht ausgeführte Prüfungen melden Führen Sie vor dem Einreichen für die geänderten Dateien das Formatierungswerkzeug, die statische Stilprüfung und die Vorabprüfungen des Quellcodebestands aus. Wenden Sie zuerst allgemeine Stilrichtlinien an und danach die sprach-, verzeichnis- oder prüfungsspezifischen Regeln, die sich aus den betroffenen Pfaden ergeben. Prüfen Sie den abschließenden Änderungsvergleich auf unbeabsichtigte Dateien, erzeugte Artefakte, uneinheitliche Benennung, veraltete Kommentare und fehlende Prüfungen. Wiederholen Sie die gezielte Validierung nach der letzten Bearbeitung, damit die gemeldeten Nachweise dem ausgelieferten Inhalt entsprechen. Melden Sie die genau ausgeführten Prüfungen, ihre Ergebnisse, nicht ausgeführte Prüfungen, den Grund für deren Nichtverfügbarkeit und das daraus verbleibende Risiko. Bezeichnen Sie eine Änderung niemals als vollständig validiert, wenn erforderliche Hardware, Werkzeuge, Berechtigungen oder die Abdeckung der kontinuierlichen Integration fehlten.