Modifier une grande base de code .NET en la gardant rapide et compatible

## Placer la vitesse des chemins critiques et la compatibilité en tête de chaque changement Traitez le dépôt comme une infrastructure critique en performances dont le comportement peut affecter de nombreuses compilations en aval. - Faites de l'efficacité à l'exécution la première priorité d'ingénierie dans les chemins critiques. Réduisez les allocations, évitez le coût des abstractions inutiles et choisissez des algorithmes qui restent efficaces à grande échelle. - Préservez la compatibilité, sauf si une modification est explicitement facultative. Un nouvel avertissement, une nouvelle erreur ou une modification de comportement peut interrompre les utilisateurs lorsque les avertissements sont traités comme des erreurs. - Gardez la modification ciblée. Respectez l'architecture et le style environnants, mais utilisez les fonctionnalités actuelles du langage lorsqu'une quantité importante de nouveau code justifie une modernisation. - N'introduisez aucun avertissement de compilateur ni d'analyseur. Supposez que les compilations officielles traitent chaque avertissement comme une erreur. - Préférez les preuves fournies par la compilation du dépôt, les sorties d'amorçage, les exemples et les tests aux suppositions. ## Écrire du C# dans le style du dépôt et avec moins d’allocations lors de l’analyse Appliquez l'outil de formatage du dépôt et `.editorconfig` avant d'inventer des règles de style locales. - Préférez la syntaxe C# actuelle prise en charge par le SDK fixé, y compris les expressions de collection lorsqu'elles améliorent la clarté. - Utilisez des espaces de noms à portée de fichier et des directives `using` compactes lorsque cela correspond à la base de code. - Respectez le style d'accolades du dépôt et utilisez `nameof` pour référencer des membres. - Utilisez la correspondance de motifs et les expressions switch lorsqu'elles rendent les conditions plus claires sans ajouter de coût. - Pour les analyses sensibles aux allocations, préférez `Span<T>`, `ReadOnlySpan<T>`, les découpages et les API `TryParse` fondées sur les spans. - Utilisez des opérations de caractères invariantes pour normaliser un caractère et le comparateur de domaine du dépôt pour les identifiants du domaine. Utilisez une comparaison ordinale pour les identifiants ordinaires hors domaine. - N'envisagez l'inlining agressif que pour de petites fonctions auxiliaires mesurées et situées dans des chemins critiques. Traitez les types référence nullables selon le mode établi dans le fichier : - Les nouveaux fichiers utilisent les types référence nullables et ne doivent pas désactiver l'analyse de nullabilité. - Les fichiers qui désactivent explicitement l'analyse de nullabilité conservent ce style ; n'y ajoutez pas d'annotations de nullabilité isolées. - Les fichiers dont l'analyse de nullabilité est active utilisent des annotations précises et une gestion explicite des valeurs nulles. - Préférez les contrôles de nullité fondés sur des motifs, comme `is null` et `is not null`. Choisissez les collections immuables selon leur modèle de mise à jour. Utilisez des collections immuables compactes appuyées sur des tableaux ou des tables de recherche figées pour les données construites une fois et lues de nombreuses fois. N'utilisez des listes ou dictionnaires immuables persistants que lorsque des mises à jour progressives sont réellement nécessaires. N'utilisez pas de chaînes de requêtes dans les chemins critiques lorsqu'une boucle directe évite des allocations. ## Revoir les changements pour leur coût dans les chemins critiques et les nouveaux avertissements Révisez les modifications comme si elles devaient s'exécuter dans un moteur de compilation largement utilisé. 1. Déterminez la fréquence d'exécution et le volume de données de chaque chemin modifié. 2. Signalez les allocations inutiles, les énumérations répétées, les opérateurs de requête, la création évitable de chaînes et les structures de recherche inefficaces dans les chemins critiques. 3. Vérifiez que l'analyse utilise des spans lorsque cela est pratique et que la sémantique de comparaison correspond au domaine. 4. Confirmez que les types de collection correspondent à leur mode de construction et d'accès. 5. Recherchez de nouveaux diagnostics, des valeurs par défaut modifiées, un ordre d'évaluation changé, un comportement de commande altéré ou d'autres différences observables de l'extérieur. 6. Traitez tout nouvel avertissement ou toute nouvelle erreur dans le comportement existant comme une modification incompatible, même si le diagnostic semble utile. 7. Autorisez des diagnostics plus stricts dans les nouveaux comportements facultatifs pour lesquels les utilisateurs choisissent délibérément le nouveau contrat. Examinez attentivement les modifications de configuration des sources de paquets. Toute nouvelle source externe exige une justification explicite, et les sources internes approuvées doivent être préférées lorsque le dépôt les définit. Ne modifiez pas les fichiers du SDK fixé, des sources de paquets, des propriétés de compilation partagées ou des versions de paquets centralisées, sauf si le travail demandé l'exige. Ne modifiez jamais les sorties de compilation générées ni le répertoire du SDK local géré par le dépôt. Mettez à jour la documentation technique associée lorsque le comportement, les API publiques, les commandes ou les consignes de dépannage changent. ## Compiler d’abord le plus petit projet et corriger les premières erreurs Commencez par la plus petite compilation capable de valider le composant modifié, puis élargissez la portée uniquement selon les exigences du contrat d'achèvement du dépôt. - Compilez un projet individuel avec la commande silencieuse standard du dépôt lorsque la modification est localisée. - Utilisez le script de compilation de l'ensemble du dépôt propre à la plateforme pour la vérification d'intégration. Respectez le délai documenté ; n'interrompez pas une compilation connue pour être longue uniquement parce qu'elle reste silencieuse. - Ne redirigez pas la sortie de compilation vers un fichier par un tube. Lorsqu'une liste d'erreurs durable est nécessaire, utilisez l'option native de journalisation dans un fichier du système de compilation afin que le comportement de la console et l'état de sortie restent fiables. - Lors de l'examen d'un sous-ensemble d'échecs de compilation, commencez par les premières erreurs. Les échecs ultérieurs en sont souvent les conséquences. - Si la compilation ne peut pas résoudre le SDK fixé, activez l'environnement d'amorçage du dépôt et vérifiez que la version attendue du SDK est active. - Après une compilation réussie de l'ensemble du dépôt, utilisez l'exécutable ou l'environnement d'amorçage généré pour la validation en aval. - Utilisez les projets d'exemple du dépôt, et non des projets externes sans rapport, pour les vérifications de bout en bout. Conservez les artefacts de compilation dans le répertoire défini par le dépôt. Ne modifiez pas manuellement des fichiers générés pour faire croire qu'une compilation a réussi. ## Tester le changement et lancer la commande nouvellement compilée avant de conclure Utilisez une séquence de vérification qui démontre à la fois le comportement modifié et le moteur de compilation produit par le dépôt. 1. Exécutez le projet de tests unitaires pertinent et, lorsque cela est utile, un filtre de test ciblé sur le scénario modifié. 2. Exécutez la suite de tests complète uniquement lorsque le contrat du dépôt ou la portée de la modification l'exige. Respectez les durées documentées et n'interrompez jamais prématurément une longue suite qui fonctionne normalement. 3. Compilez un exemple représentatif du dépôt dans l'environnement d'amorçage. 4. Appelez le point d'entrée de ligne de commande nouvellement compilé avec une commande inoffensive, telle que l'affichage de l'aide. 5. Confirmez que la compilation complète s'est terminée sans avertissement ni erreur. 6. Relisez les différences pour détecter les modifications de fichiers générés, les changements de configuration non demandés, les risques de compatibilité et la documentation manquante. L'achèvement exige des preuves, pas seulement une compilation réussie. Consignez la compilation, les tests ciblés, l'exemple et la vérification de l'exécutable réalisés, et indiquez clairement toute vérification qui n'a pas pu être effectuée. Ne prétendez pas avoir réalisé une validation complète lorsqu'une vérification limitée au composant seulement a été achevée.