Modifier un outil d'automatisation d'appareils et le vérifier sur de vrais appareils

## Classer la demande et ne lire que le code concerné Classez d’abord la demande. Une revue, un triage ou une question visant uniquement à obtenir des informations reste en lecture seule, sauf si des modifications ou une exécution sont explicitement demandées. Une demande de modification du code autorise une mise en œuvre minimale et les contrôles requis pour la surface concernée. Exposez les hypothèses et définissez un résultat observable avant toute modification. Lisez le vocabulaire durable du domaine, les décisions d’architecture applicables et la configuration ou le contrat responsable. Ne lisez pas tout le dépôt par défaut. Commencez par une recherche délimitée : - Localisez le symbole, la commande, l’option ou l’erreur au moyen d’une recherche textuelle rapide. - Lisez le module responsable, un seul utilitaire partagé et un seul appelant ou adaptateur en aval. - Dans un fichier volumineux, trouvez le type ou la fonction pertinente avant d’ouvrir une plage limitée. - Ne suivez les importations et les tests vers l’extérieur que lorsque les preuves l’exigent. Maintenez la modification dans une seule famille de commandes, une seule frontière de plateforme ou un seul groupe de modules, sauf si la tâche franchit explicitement ces limites. N’examinez pas deux implémentations de plateforme simplement parce qu’elles existent toutes les deux. Si la portée doit s’étendre, arrêtez-vous et confirmez la nouvelle limite. Déterminez avant de programmer l’incidence sur la documentation, l’aide, le schéma et les modules de compétence. Préférez les références durables vers la source de vérité aux inventaires de fichiers susceptibles de devenir obsolètes. ## Réunir le nom et les options de chaque commande dans un seul registre Attribuez à chaque commande un descripteur canonique unique qui gère son identité, ses capacités, sa politique de délai d’attente, sa politique de traitement par lots et ses projections publiques. Conservez le routage du démon ou du service dans un registre de routes, les garanties des chemins d’interaction dans une matrice typée et les noms de commandes dans un catalogue unique. Ne recréez pas de jeux de chaînes dans les gestionnaires. Gardez les routeurs de premier niveau légers et limités à l’orchestration. Acheminez chaque requête vers la famille de gestionnaires responsable ; n’accumulez pas de logique de commande dans le point d’entrée. Les décisions relatives aux capacités appartiennent à leur source de vérité, et non à des conditions dispersées. Ne laissez chaque option publique traverser que les couches qui la comprennent : 1. Définissez l’indicateur public et sa grammaire. 2. Ajoutez-la aux métadonnées et au schéma de la commande responsable. 3. Analysez-la comme entrée de commande. 4. Projetez-la dans une requête de service uniquement si l’exécution en a besoin. 5. Étendez les clients typés et les normalisateurs uniquement lorsque ces interfaces exposent l’option. 6. Faites-la parvenir au répartiteur et aux modules de plateforme uniquement après que le contrat public a prouvé qu’elle y a sa place. 7. Classez chaque option publique dans le modèle de progression de l’architecture ou de couverture. Centralisez l’analyse, la correspondance, la résolution et l’évaluation des prédicats des sélecteurs. Une action visant un élément doit accepter des sélecteurs stables ou des références enregistrées, préserver sa chaîne de sélecteurs et présenter toute divergence de réexécution comme une suggestion plutôt que de réécrire silencieusement l’état de l’utilisateur. ## Vérifier que les chemins rapides et de cache agissent comme le chemin principal Supposez que les garanties s’érodent aux frontières entre chemins. Lors de l’ajout d’un chemin rapide, délégué, mis en cache ou propre à une plateforme, classez chaque cellule concernée associant commande et chemin avant d’affirmer leur équivalence. Une entrée de registre n’est pas une preuve sémantique. Lisez l’implémentation et vérifiez qu’elle satisfait la définition de la garantie. Un chemin de repli qui ne délègue qu’après une erreur ne prouve pas l’équivalence du chemin de réussite ; le chemin rapide peut accepter une entrée que le chemin partagé refuserait. Avant de mesurer une expérience, prouvez que chaque groupe expérimental peut s’exécuter. Deux exécutions réussies ne signifient rien si la branche modifiée ne s’est jamais déclenchée. Consignez le chemin, le backend, le code de motif et les autres preuves typées nécessaires pour montrer quelle implémentation a traité la requête. Utilisez des signaux structurés plutôt que d’analyser des messages destinés aux humains. Bifurquez selon les codes de motif, les détails typés et les valeurs explicites de délai d’attente ; ne reproduisez pas la détection fondée sur le texte des erreurs. Traitez toute correspondance de message inévitable comme une dette documentée au point de décision. Composez les avertissements au moyen du générateur de réponses partagé au lieu d’écraser les avertissements antérieurs. Stockez une seule fois les métadonnées communes à toute la réponse plutôt que de répéter des octets pour chaque nœud ou élément. Avant de conserver un champ de compatibilité, déterminez s’il a été publié. Une surface non publiée peut être retirée proprement ; une surface publiée nécessite une migration et une gestion de la compatibilité. ## Garder des fichiers courts et des tests calqués sur le code source N’utilisez `unknown` qu’aux frontières de confiance, comme les entrées analysées, les charges utiles d’exécution, les erreurs interceptées et les E/S génériques. Validez une fois, puis réduisez le type à un type de domaine ou à un analyseur ciblé au lieu de propager l’incertitude dans les utilitaires internes et les formateurs. Privilégiez les contrôles d’exhaustivité au niveau des types lorsque le langage peut rendre impossibles les cas manquants. Placez les affirmations lisibles par machine avec le code qu’elles décrivent : les cellules de registre près des références vers leur mécanisme d’application, les manifestes de couverture près des tests de contrat et les commentaires de décision sur la branche qu’ils justifient. Faites en sorte que chaque module réponde à une seule question. Comme seuil d’alerte pratique, visez environ 300 lignes pour les fichiers d’implémentation ; au-delà de 500, améliorez la localité avant d’ajouter un comportement ; au-delà de 1,000, traitez le fichier comme une dette d’architecture, sauf s’il contient des données générées ou un instantané de données de test. Nommez les fichiers d’après le concept de domaine auquel ils répondent. N’utilisez les fichiers d’agrégation qu’aux frontières de paquets ; les fichiers d’agrégation internes ajoutent des étapes de navigation. Extrayez un module profondément imbriqué lorsqu’il améliore la responsabilité conceptuelle, et non uniquement pour réduire le nombre de lignes. Reproduisez la topologie du code source dans les tests. Lorsqu’un module source est scindé, scindez ses tests dans la même modification. Placez les données de test réutilisables dans un module frère nommé au lieu de dupliquer de grands objets intégrés. N’ajoutez pas d’exports au code de production dans le seul but de faciliter le test d’un détail privé. Avant de terminer, resserrez le code modifié et directement adjacent : retirez les branches obsolètes, les tests redondants, les importations inutilisées, les données de test périmées et les duplications rendues inutiles par la modification. Évitez tout nettoyage sans rapport avec celle-ci. ## Fermer les sessions d'appareil et séparer journaux et diagnostics Faites passer l’exécution des processus par l’abstraction de processus partagée. Étendez cette abstraction lorsqu’une capacité manque au lieu d’importer des primitives de processus de bas niveau dans tout le code. Traitez chaque session d’appareil ouverte manuellement comme une ressource. Consignez son nom de session, sa plateforme, l’identifiant de l’appareil et son répertoire d’état, puis fermez-la avec les mêmes valeurs avant de terminer, même après l’échec d’une expérience. N’arrêtez que les processus obsolètes identifiés avec exactitude comme appartenant à l’exécution de vérification ; ne terminez jamais de vastes groupes de processus sur la base de suppositions. Séparez les journaux de l’application, la sortie du programme d’exécution et les diagnostics de requêtes. Un seul backend doit être responsable de la capture des journaux de l’application. Stockez les diagnostics de requêtes sous la session résolue et l’identifiant de requête ; réservez les journaux de premier niveau du démon au cycle de vie et aux échecs survenant avant la résolution de la session. Centralisez les portées de diagnostic, les minuteurs, l’émission d’événements, l’occultation et la construction des chemins d’artefacts. Ne construisez pas manuellement les chemins de journaux et n’ajoutez pas de fichiers ad hoc lorsque le service de diagnostic est responsable de ces données. Normalisez les échecs présentés à l’utilisateur dans une charge utile stable comprenant un code, un message concis, une indication de rétablissement, un identifiant de diagnostic, un chemin de journal et des détails typés. Préservez ces champs lorsque vous enveloppez des erreurs. Indiquez ce qui a échoué, pourquoi lorsque la cause est connue, et la prochaine action de rétablissement. Traitez les sondes facultatives, les contrôles de cache et les vérifications préalables selon le principe du meilleur effort, sauf si le contrat de la fonctionnalité les rend obligatoires. Accordez-leur un délai d’attente plus court que celui de l’opération requise et revenez au chemin établi lorsqu’elles échouent ou renvoient une structure inutilisable. ## Choisir les tests selon ce qui a changé Commencez par le planificateur des contrôles affectés du dépôt lorsqu’il est disponible. Il doit déduire les tests ciblés et les barrières restantes des métadonnées canoniques plutôt que d’une liste écrite à la main. Associez les contrôles à la surface modifiée : - Toute modification d’une source typée exige une vérification des types et un formatage. - La configuration de la chaîne d’outils ou du compilateur exige la barrière d’outillage et la compilation des déclarations. - Les modifications d’un service ou d’un gestionnaire partagé exigent l’ensemble ciblé de tests unitaires. - Les modifications de la forme des réponses ou de la frontière d’un fournisseur exigent des contrôles d’intégration du fournisseur et de couverture. - Les modifications du programme d’exécution natif exigent de reconstruire l’artefact de test natif. - Un comportement multiplateforme exige la suite d’intégration multiplateforme. - Un travail portant uniquement sur la documentation ne nécessite des tests d’exécution que lorsqu’un contrat plus précis l’impose. N’exécutez pas de vastes tests d’intégration par défaut lorsque des preuves ciblées suffisent. À l’inverse, ne considérez pas qu’une modification concernant un appareil est prête en vous fondant uniquement sur des tests unitaires. Gardez les tests centrés sur le comportement. N’affirmez pas ce que les types statiques prouvent déjà. Les tests unitaires ne doivent pas attendre en temps réel ; injectez un budget temporel, déduisez-en la cadence ou vérifiez que ce budget a été correctement transmis. Lorsqu’une barrière d’application des règles détecte un indicateur non classé, une cellule de garantie manquante, un scénario non couvert, un contournement de la construction des réponses ou un défaut d’équivalence entre règles, classez ou couvrez le nouveau comportement. Ne désactivez jamais la barrière et n’ajoutez pas d’entrée inexpliquée à la liste d’autorisation. ## Reconstruire avant de vérifier sur de vrais appareils ou des simulateurs Avant la vérification manuelle, reconstruisez chaque artefact réellement consommé par l’environnement d’exécution, redémarrez les services qui ne se rechargent pas dynamiquement et invalidez ou remplacez tout programme d’exécution adopté susceptible de continuer à fournir un ancien binaire natif. Un test effectué sur une sortie périmée constitue un faux négatif, et non une preuve du produit. Prouvez quel backend a traité l’exécution. Capturez un instantané ou une réponse d’état lisible par machine et comparez l’identifiant du backend et la version de l’utilitaire au paquet actuel. Un repli silencieux ne constitue une preuve valable que lorsque le comportement de repli est la fonctionnalité testée. Utilisez des appareils, simulateurs ou émulateurs différents pour les arbres de travail simultanés, car un état isolé du démon n’isole pas les cibles physiques. Suivez le guide de configuration propre à l’application de test ; l’installation d’une application ne suffit pas, sauf si les contrôles de compilation, de serveur de développement et de surface prouvent que la version prévue fonctionne. Classez les perturbations de l’environnement avant de déboguer le code du produit. Reproduisez les échecs dus à la contention de façon isolée et sur la base inchangée sous la même charge. Un ensemble changeant d’échecs qui réussit isolément indique probablement une contention ; un échec stable dans le chemin modifié constitue une preuve plus solide de régression. Si un bac à sable empêche l’utilisation d’un écouteur local, d’un pont d’appareil ou d’un outil natif requis, relancez l’opération par le chemin privilégié approuvé au lieu de diagnostiquer le refus du bac à sable comme un défaut du produit. Si la vérification en conditions réelles reste bloquée, indiquez précisément l’appareil, l’autorisation, la commande ou le service requis et conservez le risque résiduel. ## Relire le vrai chemin de la commande et rendre compte avec des résultats sur appareil Évaluez le travail au regard du problème qui l’a motivé et des décisions d’architecture acceptées, et non uniquement du diff. Suivez la route de production depuis la surface de commande, à travers le routage des requêtes, jusqu’au backend de la plateforme. Un test qui contourne le routeur ou simule l’interface critique ne prouve pas le comportement livré. Pour chaque test de régression essentiel, identifiez l’ancienne implémentation, la suppression ou la réversion qui devrait le faire échouer. Si le test reste réussi après le retour du défaut, il est sans portée et doit être renforcé. Séparez la restructuration prévue des changements de comportement dissimulés dans la forme de sortie, la propagation des avertissements, les détails d’erreur, les chemins d’artefacts, les niveaux de nouvelle tentative et les replis. Vérifiez les modifications apparentées et l’ordre des branches lorsque l’implémentation dépend d’une autre modification. Placez la publication externe ou le push derrière une chaîne de réussite unique afin qu’ils ne puissent pas s’exécuter après l’échec d’une commande de formatage, de typage, de lint ou de test. Maintenez les commits et les pull requests dans un périmètre restreint, utilisez le style de titre habituel du projet et n’ouvrez par défaut une revue prête à être examinée que lorsque le travail est achevé. Résumez le comportement visible par l’utilisateur, la validation pertinente, les preuves obtenues sur des appareils réels et les véritables compromis. Ne déclarez pas l’intégration continue réussie sur la seule base d’une exécution locale de tests unitaires et ne présentez pas une modification de plateforme comme prête à fusionner sans preuves actuelles en conditions réelles. Indiquez l’incidence sur la documentation ou l’aide, le périmètre modifié, tout chemin non vérifié et le blocage exact. Avant le transfert, fermez chaque session et rendez compte de chaque ressource ouverte pendant la vérification. Signalez toute session, tout processus, tout répertoire d’état ou tout artefact qui n’a pas pu être nettoyé.