Eine große .NET-Codebasis ändern und dabei schnell und kompatibel halten

## Bei jeder Änderung Tempo kritischer Pfade und Kompatibilität voranstellen Behandle das Quellcodearchiv als leistungskritische Infrastruktur, deren Verhalten zahlreiche nachgelagerte Kompilierungen beeinflussen kann. - Mache die Laufzeiteffizienz in kritischen Ausführungspfaden zur wichtigsten technischen Priorität. Minimiere Speicherzuweisungen, vermeide unnötigen Abstraktionsaufwand und wähle Algorithmen, die auch bei wachsendem Umfang effizient bleiben. - Bewahre die Kompatibilität, sofern eine Änderung nicht ausdrücklich wahlweise aktiviert wird. Neue Warnungen, Fehler oder Verhaltensänderungen können Anwendungen von Nutzern beschädigen, wenn Warnungen als Fehler behandelt werden. - Halte die Änderung zielgerichtet. Passe dich an die umgebende Architektur und den Stil an, nutze jedoch aktuelle Sprachmerkmale, wenn umfangreicher neuer Code eine Modernisierung rechtfertigt. - Führe keine neuen Compiler- oder Analysewarnungen ein. Gehe davon aus, dass offizielle Kompilierungen jede Warnung als Fehler behandeln. - Bevorzuge Belege aus der eigenen Kompilierung, den Bereitstellungsausgaben, Beispielen und Tests des Quellcodearchivs gegenüber Annahmen. ## C# im Stil des Quellcodearchivs schreiben und beim Parsen weniger Speicher zuweisen Wende das Formatierungswerkzeug des Quellcodearchivs und `.editorconfig` an, bevor du eigene lokale Stilregeln erfindest. - Bevorzuge die aktuelle, vom festgelegten SDK unterstützte C#-Syntax einschließlich Collection Expressions, wenn sie die Verständlichkeit erhöhen. - Verwende dateibezogene Namensräume und kompakte `using`-Anweisungen, wenn dies zur Codebasis passt. - Befolge den Klammerstil des Quellcodearchivs und verwende `nameof` für Verweise auf Programmelemente. - Nutze Musterabgleich und switch-Ausdrücke, wenn sie Bedingungen ohne zusätzlichen Aufwand verständlicher machen. - Bevorzuge bei zuweisungsempfindlicher Analyse `Span<T>`, `ReadOnlySpan<T>`, Ausschnitte und spanbasierte `TryParse`-APIs. - Verwende kulturunabhängige Zeichenoperationen zur Normalisierung einzelner Zeichen und den vorgegebenen Domänenvergleicher für Domänenbezeichner. Verwende Ordinalvergleiche für gewöhnliche Bezeichner außerhalb der Domäne. - Erwäge aggressives Inline-Ersetzen nur für kleine, gemessene Hilfsfunktionen in kritischen Ausführungspfaden. Behandle nullable Referenztypen entsprechend dem in der Datei festgelegten Modus: - Neue Dateien verwenden nullable Referenztypen und dürfen die Nullbarkeitsanalyse nicht abschalten. - Dateien, welche die Nullbarkeitsanalyse ausdrücklich abschalten, behalten diesen Stil bei; füge dort keine vereinzelten Nullbarkeitsanmerkungen hinzu. - Dateien mit aktiver Nullbarkeitsanalyse verwenden genaue Anmerkungen und eine ausdrückliche Nullwertbehandlung. - Bevorzuge musterbasierte Nullwertprüfungen wie `is null` und `is not null`. Wähle unveränderliche Sammlungen nach ihrem Aktualisierungsmuster. Verwende kompakte, feldgestützte unveränderliche Sammlungen oder eingefrorene Nachschlagetabellen für Daten, die einmal aufgebaut und häufig gelesen werden. Verwende dauerhafte unveränderliche Listen oder Wörterbücher nur, wenn schrittweise Aktualisierungen tatsächlich erforderlich sind. Nutze in kritischen Ausführungspfaden keine Abfrageketten, wenn eine direkte Schleife Speicherzuweisungen vermeidet. ## Änderungen auf Kosten in kritischen Pfaden und neue Warnungen prüfen Prüfe Änderungen unter der Annahme, dass sie in einer weit verbreiteten Kompilierungsmaschine ausgeführt werden. 1. Ermittle Ausführungshäufigkeit und Datenmenge jedes geänderten Pfads. 2. Kennzeichne unnötige Speicherzuweisungen, wiederholte Aufzählungen, Abfrageoperatoren, vermeidbare Zeichenkettenerzeugung und ineffiziente Nachschlagestrukturen in kritischen Pfaden. 3. Prüfe, ob die Analyse an geeigneten Stellen Spans verwendet und die Vergleichsbedeutung zur Domäne passt. 4. Bestätige, dass die Sammlungstypen zu ihrem Aufbau- und Zugriffsmuster passen. 5. Suche nach neuen Diagnosen, geänderten Standardwerten, umgeordneter Auswertung, geändertem Befehlsverhalten und anderen von außen sichtbaren Unterschieden. 6. Behandle jede neue Warnung oder jeden neuen Fehler im bestehenden Verhalten als inkompatible Änderung, selbst wenn die Diagnose hilfreich erscheint. 7. Erlaube strengere Diagnosen in neuen, wahlweise aktivierten Verhaltensweisen, bei denen Nutzer den neuen Vertrag bewusst auswählen. Prüfe Änderungen an Paketquellen sorgfältig. Neue externe Quellen benötigen eine ausdrückliche Begründung; vom Quellcodearchiv festgelegte, freigegebene interne Quellen sind zu bevorzugen. Ändere Dateien für das festgelegte SDK, Paketquellen, gemeinsame Kompilierungseigenschaften oder zentral verwaltete Paketversionen nur, wenn die angeforderte Arbeit dies erfordert. Bearbeite niemals erzeugte Kompilierungsausgaben oder das vom Quellcodearchiv verwaltete lokale SDK-Verzeichnis. Aktualisiere zugehörige technische Dokumentation, wenn sich Verhalten, öffentliche APIs, Befehle oder Hinweise zur Fehlerbehebung ändern. ## Zuerst das kleinste Projekt kompilieren und die frühesten Fehler beheben Beginne mit der kleinsten Kompilierung, die die geänderte Komponente nachweisen kann, und erweitere den Umfang nur so weit, wie es der Abschlussvertrag des Quellcodearchivs verlangt. - Kompiliere bei einer örtlich begrenzten Änderung ein einzelnes Projekt mit dem standardmäßigen stillen Kompilierungsbefehl des Quellcodearchivs. - Verwende zur Integrationsprüfung das plattformspezifische Skript für die Gesamtkompilierung. Halte die dokumentierte Zeitgrenze ein; brich eine bekanntermaßen lang laufende Kompilierung nicht allein deshalb ab, weil sie keine Ausgabe erzeugt. - Leite Kompilierungsausgaben nicht in eine Datei um. Wenn eine dauerhafte Fehlerliste benötigt wird, verwende die eingebaute Dateiprotokollierung des Kompilierungssystems, damit Konsolenverhalten und Beendigungsstatus verlässlich bleiben. - Beginne bei der Untersuchung eines Teils der Kompilierungsfehler mit den frühesten Fehlern. Spätere Fehler sind oft nur Folgen. - Kann die Kompilierung das festgelegte SDK nicht auflösen, aktiviere die Bereitstellungsumgebung des Quellcodearchivs und prüfe, ob die erwartete SDK-Version aktiv ist. - Verwende nach einer erfolgreichen Gesamtkompilierung die erzeugte Bereitstellungsausführung oder -umgebung für nachgelagerte Prüfungen. - Nutze Beispielprojekte des Quellcodearchivs statt unbeteiligter externer Projekte für durchgängige Prüfungen. Bewahre Kompilierungsartefakte im dafür festgelegten Verzeichnis auf. Bearbeite erzeugte Dateien nicht von Hand, um eine erfolgreiche Kompilierung vorzutäuschen. ## Die Änderung testen und den neu gebauten Befehl vor dem Abschluss ausführen Verwende eine Prüffolge, die sowohl das geänderte Verhalten als auch die vom Quellcodearchiv erzeugte Kompilierungsmaschine nachweist. 1. Führe das einschlägige Einheitstestprojekt und, wenn hilfreich, einen auf das geänderte Szenario begrenzten Testfilter aus. 2. Führe die vollständige Testsammlung nur aus, wenn der Vertrag des Quellcodearchivs oder der Änderungsumfang dies verlangt. Beachte dokumentierte Laufzeiten und brich eine ordnungsgemäß laufende, lang dauernde Testsammlung niemals vorzeitig ab. 3. Kompiliere ein repräsentatives Beispiel des Quellcodearchivs in der Bereitstellungsumgebung. 4. Rufe den neu kompilierten Befehlszeileneinstiegspunkt mit einem harmlosen Befehl wie der Hilfeausgabe auf. 5. Bestätige, dass die Gesamtkompilierung ohne Warnungen oder Fehler abgeschlossen wurde. 6. Lies die Änderungen erneut und suche nach Bearbeitungen erzeugter Dateien, nicht angeforderten Konfigurationsänderungen, Kompatibilitätsrisiken und fehlender Dokumentation. Ein Abschluss erfordert Belege, nicht nur eine erfolgreiche Kompilierung. Protokolliere die ausgeführte Kompilierung, gezielten Tests, Beispiele und Prüfungen der ausführbaren Datei und benenne klar jede nicht durchführbare Prüfung. Melde keine vollständige Validierung, wenn nur eine Prüfung auf Komponentenebene abgeschlossen wurde.