Modifier le code d’un grand dépôt à plusieurs langages en ne compilant et testant que le nécessaire

## Rechercher et planifier, puis faire et tester la plus petite modification Utilisez une séquence reproductible pour chaque modification : 1. Étudiez la demande, le code concerné, les interfaces des dépendances, les tests existants et les modes de défaillance connus. 2. Élaborez un plan d’implémentation général et remettez en question ses hypothèses, ses cas limites et ses risques opérationnels. 3. Examinez du code similaire pour comprendre l’organisation, les conventions de nommage, la gestion des erreurs et les modèles de test du dépôt. 4. Présentez le plan uniquement si l’utilisateur le demande ; sinon, poursuivez l’implémentation. 5. Implémentez la plus petite modification cohérente qui satisfasse la demande. 6. Vérifiez l’exactitude des API, la clarté, les performances, la lisibilité et toute extension involontaire du périmètre. 7. Exécutez le formatage, des compilations ciblées et les tests pertinents, puis corrigez les échecs de manière itérative. Ne considérez pas la rédaction d’un brouillon comme un achèvement. Une modification n’est prête qu’après la revue et la validation de l’implémentation et du comportement directement concerné. ## Avant de modifier, suivre le modèle du code similaire le plus proche Lisez les consignes de contribution générales du dépôt ainsi que toutes les instructions propres aux chemins qui régissent les fichiers à modifier. Trouvez l’exemple fonctionnel le plus proche, comme une classe apparentée, un paquet voisin, un test similaire ou un flux de travail connexe, et suivez sa structure établie, sauf si la tâche exige un écart délibéré. Vérifiez les API des dépendances et les cas limites à partir d’interfaces faisant autorité ou d’utilisations existantes. Repérez les tests actuels avant d’en créer de nouveaux et intégrez la nouvelle couverture aux infrastructures existantes du dépôt au lieu d’inventer un dispositif parallèle. Concentrez l’étude sur le comportement demandé. Ne mêlez pas à la modification des renommages, des déplacements de répertoires, des changements massifs de formatage ou des nettoyages architecturaux sans rapport. ## Avant de tester, vérifier les outils et le matériel disponibles Avant de choisir des commandes, déterminez quels compilateurs, environnements d’exécution, outils de compilation, conteneurs, accélérateurs et identifiants sont réellement disponibles. Distinguez une capacité indisponible d’une défaillance du produit : l’absence d’un appareil, un environnement de conteneur non pris en charge ou une chaîne d’outils manquante ne prouvent pas que le code est défectueux. Utilisez le conteneur ou l’environnement de développement standard du dépôt lorsqu’il est pris en charge et nécessaire à la reproductibilité. Sinon, exécutez toutes les vérifications pertinentes disponibles dans l’environnement actuel et identifiez la plus petite commande restante qui exige une autre machine ou une intervention de l’utilisateur. N’affirmez jamais qu’un test indisponible a réussi. Indiquez la limite exacte, la validation accomplie sans ce test et le risque résiduel. ## Compiler et tester seulement les parties touchées par la modification Privilégiez les préréglages et les scripts auxiliaires fournis par le dépôt plutôt que des suites de commandes assemblées manuellement. Recensez les préréglages pris en charge, choisissez celui qui correspond au composant modifié et au niveau du langage, et ne ciblez que les éléments de compilation, tests unitaires, tests d’intégration ou vérifications du compilateur pertinents. Utilisez les informations de dépendance pour inclure les composants en aval affectés par une modification partagée ou fortement dépendante. Pour une modification locale, évitez de recompiler les paquets sans rapport. Réservez les compilations et suites de tests complètes aux modifications transversales, aux contrôles de publication ou aux règles du dépôt qui les imposent explicitement. Consignez pourquoi le périmètre choisi est suffisant. Une vérification restreinte n’a de valeur que si son lien avec la modification est clair. ## Tester chaque langage et architecture matérielle à sa façon Traitez chaque langage ou couche de paquet selon sa propre interface. Les bibliothèques natives peuvent exiger des réglages de compilateur, de norme du langage et d’architecture, tandis que les paquets de langages de script peuvent nécessiter des versions d’environnement d’exécution, des dépendances supplémentaires et des points d’entrée de test propres au paquet. Ne transmettez pas les paramètres d’un écosystème à un autre. Pour le code sensible à l’architecture, distinguez les vérifications limitées à l’hôte, celles limitées à la compilation, les simulateurs ou cibles virtuelles et les tests qui exigent du matériel physique. Sélectionnez des architectures représentatives selon le comportement modifié et la plage de compatibilité prise en charge, au lieu de compiler toutes les variantes par défaut. Lorsqu’un composant partagé change, examinez le graphe des dépendances et validez les consommateurs les plus susceptibles de révéler des régressions de compatibilité. ## Lancer d’abord les vérifications peu coûteuses et ne pas couper trop tôt les builds lents Supposez que les compilations volumineuses, les matrices de tests générées et les suites reposant sur du matériel peuvent prendre beaucoup de temps. Fixez des délais d’expiration réalistes, utilisez les caches pris en charge, limitez les architectures et les cibles pendant les itérations, puis élargissez la couverture uniquement lorsque le risque ou l’étape de publication justifie le coût. Une longue durée ne prouve pas à elle seule un blocage. N’annulez pas une compilation ou un test en cours uniquement parce qu’il est lent ; arrêtez-le seulement en présence d’une preuve concrète d’échec, d’une limite opérationnelle explicite ou d’une instruction de l’utilisateur. Organisez la validation par étapes afin d’obtenir d’abord les retours les moins coûteux : formatage et vérifications statiques, compilation ciblée, tests exécutables sur l’hôte, puis suites spécialisées ou dépendantes du matériel. Préservez la couverture finale requise, même si les premières itérations utilisent un sous-ensemble plus petit. ## Réduire la CI pendant l’itération, mais la lancer en entier avant la fusion Utilisez la détection des modifications et les matrices de tâches pour exécuter les tâches pertinentes pour les composants concernés. Des matrices de substitution temporaires ou des contrôles d’omission peuvent réduire le coût des premières itérations, notamment pour les modifications d’infrastructure ou les zones à fortes dépendances, mais ils doivent rester visibles et auditables. Traitez une couverture réduite de la CI comme un blocage de la fusion. Avant toute fusion, rétablissez la configuration complète exigée par le dépôt et obtenez une exécution réussie sans substitution temporaire ni contrôle d’omission. Ne retirez pas la substitution d’un autre contributeur et n’en modifiez pas le périmètre sans instruction explicite. Maintenez la configuration de substitution structurellement valide lorsque le flux de travail attend une valeur vide plutôt que sa suppression. Vérifiez que l’agrégation des résultats se termine en échec par sécurité lorsque des tâches obligatoires échouent ou qu’une couverture réduite reste active. ## Lancer formateur et linter, et signaler les vérifications non effectuées Avant de valider les modifications, exécutez sur les fichiers modifiés l’outil de formatage, l’analyseur de style et les vérifications préalables à la validation du dépôt. Appliquez d’abord les consignes de style communes, puis les règles propres au langage, au répertoire ou aux tests déterminées par les chemins concernés. Examinez la comparaison finale pour repérer les fichiers ajoutés par inadvertance, les artefacts générés, les noms incohérents, les commentaires obsolètes et les tests manquants. Relancez la validation ciblée après la dernière modification afin que les preuves communiquées correspondent au contenu livré. Communiquez les vérifications exactes effectuées, leurs résultats, les vérifications non exécutées, la raison de leur indisponibilité et le risque résiduel qui en découle. Ne présentez jamais une modification comme entièrement validée si le matériel, les outils, les autorisations ou la couverture de CI nécessaires faisaient défaut.