Développer un framework de flux de données en Rust pour la robotique et l'IA en choisissant les tests selon le changement

## Organiser l'espace de travail Rust et répartir l'exécution en quatre rôles Organisez le système comme un espace de travail Rust doté de liaisons pour Python, C et C++. Conservez la version minimale de la chaîne d’outils et les métadonnées communes des paquets à la racine de l’espace de travail, tout en permettant à des crates ou exemples explicitement documentés de fixer des versions indépendantes. Utilisez quatre rôles d’exécution aux responsabilités clairement définies : - Un client en ligne de commande construit, démarre, arrête et inspecte les flux de données. - Un coordinateur gère le cycle de vie distribué entre les machines. - Un démon par machine lance les nœuds et gère les communications locales et distantes. - Les nœuds exécutent le code utilisateur dans des processus, tandis que les opérateurs s’exécutent dans le processus lorsqu’une surcharge moindre est nécessaire. Conservez les définitions des messages et des protocoles dans une bibliothèque partagée, l’analyse des descripteurs et les utilitaires de construction dans une bibliothèque centrale, et les API des langages dans des paquets distincts. Ne laissez pas les exigences de construction des liaisons de langage contaminer les constructions normales limitées à Rust. ## Construire les liaisons de langage à part de l'espace de travail Rust Construisez l’espace de travail Rust en excluant les paquets de liaisons de langage qui nécessitent un outil d’empaquetage distinct. Construisez plutôt ces paquets avec leur chaîne d’outils de liaison native, sans les forcer à passer par la commande ordinaire de l’espace de travail. Prenez en charge trois niveaux d’itération : l’espace de travail complet, un paquet et une cible de test. Exécutez les vérifications, les tests, l’analyse statique et le formatage avec les commandes canoniques de l’espace de travail, et installez les outils locaux en ligne de commande avec des dépendances verrouillées. Construisez avant d’exécuter l’analyse statique, les tests, les instantanés d’intégration ou les vérifications de documentation. Les cibles d’exemple nécessitent une vérification explicite des exemples, car une vérification générale de l’espace de travail peut ne pas les compiler. Conservez des tests rapides de paquet pour les itérations, mais revenez à l’ensemble de l’espace de travail concerné avant toute publication. Si un nouveau flux de données d’exemple est ajouté, exécutez la suite de tests de fumée des exemples dans le mode de langage pris en charge. ## Garder clairs les trois modèles de communication et la règle de mémoire partagée Définissez les flux de données de manière déclarative. Les nœuds s’abonnent à des sorties nommées et déclarent leurs propres sorties. Fournissez des sources de temporisation et indiquez explicitement leur fréquence ou leur intervalle dans le descripteur. Préservez trois modèles de communication distincts exposés aux utilisateurs : - Topic est le flux de publication/abonnement par défaut. - Service suit le modèle requête/réponse et corrèle les messages au moyen d’un `request_id`. - Action représente l’objectif, le retour d’information, le résultat et l’annulation au moyen de `goal_id` et `goal_status`. Utilisez des canaux bornés à producteurs multiples pour le routage interne des événements et un environnement d’exécution asynchrone pour l’orchestration. Utilisez un transport distribué de publication/abonnement entre les machines et une horloge logique hybride pour l’ordre causal. Pour le trafic entre nœuds locaux, envoyez les messages de plus de 4 KB par mémoire partagée sans copie, et les messages plus petits par TCP. Rendez explicites le seuil, la propriété et le comportement de repli ; ne fusionnez jamais la sémantique de la mémoire partagée locale et celle du réseau distant dans un chemin unique non documenté. ## Relire et simplifier chaque commit avant de lancer les tests Chaque commit doit franchir les contrôles suivants avant publication : 1. Examinez le diff afin de détecter les défauts structurels, de sécurité et de logique. 2. Simplifiez la complexité, les doublons et l’inefficacité inutiles. 3. Vérifiez le formatage et l’analyse statique en traitant les avertissements comme des erreurs, exécutez au minimum les tests du paquet concerné, puis les tests de l’espace de travail complet avant publication. 4. Compilez les cibles d’exemple afin que les ruptures de signature d’API ne puissent pas rester masquées en dehors du graphe normal de l’espace de travail. Utilisez un contrôle local rapide avant chaque commit, comprenant le formatage, l’analyse statique, l’audit des dépendances, le budget de raccourcis non sûrs et la vérification des fautes de frappe. Exécutez ensuite la commande de test complète requise avant publication. Ne sautez pas un contrôle qui a échoué et ne comptez pas sur une CI distante plus lente pour détecter le problème. Corrigez l’échec et réexécutez le contrôle concerné. Respectez l’ordre : la revue et la simplification rendent les défauts de conception moins coûteux à corriger avant les tests étendus. ## Choisir les tests poussés selon le risque plutôt qu'à chaque commit N’exécutez pas toutes les suites approfondies à chaque commit et ne les ajoutez pas toutes à la CI des demandes d’intégration. Sélectionnez-les selon le périmètre de la modification : - Utilisez la suite locale complète, y compris la couverture, avant une publication importante lorsqu’un niveau de confiance supplémentaire est nécessaire. - Utilisez une validation approfondie avec analyse de mutation et de compatibilité pour les modifications à haut risque ou de Tier 1. - Utilisez des exécutions nocturnes de plusieurs heures pour couvrir la parité multiplateforme, les propriétés, l’interpréteur, les preuves formelles et les tests de bout en bout. - Utilisez le contrôle de publication avant la distribution ; conservez la revue de sécurité indépendante, l’utilisation interne et la validation de migration comme des contrôles distincts menés par des personnes. - N’utilisez un audit complet par mutation que pour évaluer les tests avec une qualité de publication ou pour une investigation ciblée, car il peut prendre de 10 à 18 heures. - Exécutez les flux de données d’exemple de bout en bout après avoir modifié les API des nœuds, le comportement des commandes ou les descripteurs. - Exécutez les preuves formelles lors de la modification de modules soumis à une exigence de preuve, et l’optimisation guidée par profil sur l’OS et l’architecture cibles, car les profils ne sont pas transférables. Considérez la couverture, la mutation, la compatibilité, les exemples, la vérification formelle et le profilage des performances comme des éléments de preuve complémentaires, et non comme des substituts interchangeables. ## Garder la CI des pull requests rapide et lancer les longs jobs la nuit Maintenez la CI des demandes d’intégration suffisamment légère pour fournir rapidement un retour bloquant. Elle doit couvrir le formatage, l’analyse statique où les avertissements sont traités comme des erreurs, les tests du cœur, les chemins de défaillance de bout en bout, les contrats sémantiques, les régressions de benchmark, les fautes de frappe, les contrôles de la chaîne d’approvisionnement, les budgets de raccourcis non sûrs et les licences. N’alourdissez pas le pipeline bloquant avec des tâches de plusieurs heures. Planifiez séparément la validation étendue : - Exécutez les tests de plateforme sous Linux, macOS et Windows. - Testez les exemples, les modèles de ligne de commande, les nœuds en langage dynamique, les benchmarks et la compilation croisée. - Couvrez le cycle de vie distribué, l’enregistrement et la relecture, la reconnexion, la reconstruction de l’état, l’affinité CPU, les moteurs de stockage et les adaptateurs de pont. - Vérifiez le compilateur minimal pris en charge et tous les bancs de preuves formelles. Les échecs nocturnes doivent produire un signal de régression suivi, mais ne sont pas obligés de bloquer une demande d’intégration sans rapport. Avant la fusion, exécutez localement les vérifications des plateformes non configurées par défaut ou des exemples lorsque la modification dépend de ces chemins. ## Écrire d'abord un test qui échoue, puis juste le code qui le fait passer Toutes les nouvelles fonctionnalités et corrections de bogues suivent RED-GREEN-IMPROVE : 1. RED : écrivez le plus petit test qui définit le comportement attendu et vérifiez qu’il échoue pour la raison prévue. 2. GREEN : implémentez uniquement le code nécessaire pour faire réussir ce test. 3. IMPROVE : refactorisez tout en maintenant au vert les tests ciblés et ceux du paquet concerné. Choisissez le premier niveau de test selon le comportement. Commencez les fonctions de bibliothèque avec des tests unitaires, le comportement du coordinateur ou du démon avec des tests d’intégration, les modifications de commandes avec des tests de fumée en réseau, les fonctionnalités de flux de données avec des tests de fumée en réseau et en local, et les corrections de bogues avec le test de régression le plus ciblé qui reproduit le défaut. Une fois le test ciblé réussi, exécutez les tests du paquet concerné, l’analyse statique avec les avertissements traités comme des erreurs et les vérifications de formatage. Si la modification touche le client de commande, le coordinateur ou le démon, exécutez également les tests de fumée en série lorsque des ports ou processus partagés exigent une isolation. ## Faire passer les flux d'exemple par les tests de fumée en réseau et en local Proposez deux modes de test de fumée : - Le mode réseau démarre l’environnement d’exécution distribué, lance un flux de données détaché, interroge son état jusqu’à la fin, puis arrête et démonte l’environnement d’exécution. - Le mode local exécute le flux de données dans un seul processus avec une échéance d’arrêt explicite. Les nouveaux flux de données d’exemple doivent réussir dans les deux modes. Partagez la préparation coûteuse de la construction au moyen d’un garde exécuté une seule fois, plutôt que de reconstruire pour chaque test. Conservez les tests de bout en bout du transport des commandes et de la tolérance aux pannes séparés des tests unitaires ordinaires. Les suites de tests de fumée doivent nettoyer les processus et les ports aussi bien en cas de réussite que d’échec, afin de ne pas contaminer les tests ultérieurs. Excluez de l’ensemble de tests de fumée par défaut les exemples qui nécessitent du matériel indisponible, une saisie interactive, une configuration sur plusieurs machines ou des chaînes d’outils natives non prises en charge, mais documentez la limite d’exclusion et fournissez un moyen ciblé de les exécuter. ## Garder les modifications ciblées et indiquer précisément quels contrôles ont tourné Formatez avec l’outil de formatage par défaut du dépôt avant de soumettre des modifications. Discutez des changements de conception non triviaux dans le canal de décision du projet avant leur implémentation. Ne corrigez pas des avertissements sans rapport et ne refactorisez pas du code sans rapport dans la même modification. Limitez le périmètre du patch afin que les échecs, la revue et le retour arrière restent attribuables. Traitez les paquets de langage et les binaires en ligne de commande comme des surfaces de distribution distinctes. Vérifiez pour chacun les contrôles appropriés de paquet, de liaison, de compatibilité et de publication. N’utilisez un profil de publication optimisé qu’après la réussite des contrôles de correction. Les travaux de performance doivent indiquer la plateforme cible et comparer une référence reproductible avec la construction optimisée. Avant le transfert, indiquez quels contrôles rapides, complets, approfondis, nocturnes, d’exemples, de preuve ou de performance ont réellement été exécutés et lesquels restent non vérifiés. Ne laissez jamais entendre que la réussite d’un niveau prouve celle d’un autre niveau.