Sujet : tooling
-
Choisir un outil ou une compétence avec un modèle de décision : Choice pour classer, Noul pour s'abstenir
Pourquoi un Choice portant sur des outils candidats répond à une question relative (quel candidat convient le mieux) alors qu'un Noul par candidat répond à une question absolue (ce tour a-t-il seulement besoin d'un outil), et comment le cookbook de suggestion de compétences de TypeSafe combine les deux sur un catalogue de 182 compétences : une première requête classe tous les candidats, une seconde lit les trois premiers et peut tous les rejeter.
-
Données d'amorçage et fixtures pour bases de données locales : petites, idempotentes et versionnées avec le schéma
Séparer les données de référence (nécessaires partout), les données d'exemple (développement et démonstrations) et les données de test (créées par les tests) ; écrire le script d'amorçage comme du code idempotent avec des upserts sur des clés naturelles, garder le jeu d'exemples petit et nommé, l'exécuter après les migrations à la fois dans le script d'installation et en intégration continue, et ne jamais amorcer les machines de développement à partir de données de production brutes.
-
Concevoir un pipeline d'intégration continue
Un pipeline d'IC devrait être rapide, autotestable et identique pour chaque changement : construire à partir d'un checkout propre, exécuter linters et tests par étapes, échouer bruyamment, et garder la durée totale assez courte pour que les gens l'attendent.
-
Garder l'IC et les vérifications locales identiques : un point d'entrée unique, des outils figés, le même conteneur
Une vérification qui passe en local devrait passer en IC et inversement : définir chaque vérification une seule fois comme une tâche nommée, figer la chaîne d'outils dans un manifeste versionné à partir duquel l'amorçage et le pipeline installent tous deux, exécuter l'IC dans la même image de conteneur que l'environnement de développement, fixer la locale et le fuseau horaire, et traiter tout échec propre à l'IC comme un bug de parité à éliminer avant de corriger le symptôme.
-
Le formatage et le linting automatisés comme contrat d'équipe
Déléguer la mise en forme à un formateur et les vérifications mécaniques à un linter retire les débats de style de la revue ; EditorConfig, PEP 8 et des outils tels que Ruff montrent comment ce contrat peut être encodé dans le dépôt.
-
Choisir un format de configuration : JSON, YAML ou TOML
JSON (RFC 8259) est strict et lisible partout, mais ne connaît pas les commentaires ; YAML est bien lisible, mais les valeurs non citées sont typées selon des motifs ; TOML est conçu pour la configuration, avec commentaires, types explicites et tables. Le choix dépend de qui modifie le fichier et de ce qui le lit — et chaque format nécessite, après l'analyse, une vérification par rapport à un schéma.
-
Vérifier si un wrapper de tâche a masqué l'échec de sa commande interne
Déterminer si une tâche signalée comme réussie a effectivement propagé le résultat du compilateur, du lanceur de tests ou de la commande de migration dont dépend ce succès.
-
Un script d'installation du premier jour qui se vérifie lui-même : bootstrap, doctor, test de fumée
Une seule commande après le clonage produit soit un environnement fonctionnel, soit une liste précise de ce qui manque et comment le corriger : un script doctor en lecture seule vérifie chaque prérequis, un bootstrap idempotent n'installe que ce que les vérifications signalent manquant, et un test de fumée décide du code de sortie ; l'intégration continue l'exécute depuis une machine propre afin qu'il ne se dégrade pas entre deux arrivées.
-
Typage graduel en Python avec les indications de type
Les indications de type (PEP 484) sont des annotations facultatives vérifiées par des outils externes tels que mypy ; les ajouter progressivement à une base de code permet de détecter des erreurs d'interface et de documenter l'intention sans changer le comportement à l'exécution.
-
Choisir un format de configuration : JSON, YAML ou TOML
JSON est strict et universel mais ne permet pas de commentaires ; YAML est lisible mais présente un typage implicite parfois surprenant ; TOML est explicite et se prête bien aux commentaires pour des structures plates à modérément imbriquées. Le choix dépend de qui édite le fichier et de ce qui l'analyse.
-
EditorConfig et paramètres d'éditeur versionnés : les petites conventions qui arrêtent les diffs d'espaces
Un fichier .editorconfig fixe l'indentation, les fins de ligne, le jeu de caractères et les sauts de ligne finaux par type de fichier, communs à tous les éditeurs, avant même qu'un formateur ne s'exécute ; les paramètres d'espace de travail de l'éditeur versionnés à ses côtés doivent encoder des décisions de projet comme le format à l'enregistrement, pas des préférences personnelles.
-
Environnements virtuels : un état d'interpréteur par projet
Un environnement virtuel est un site-packages privé lié à un interpréteur ; en créer un par projet évite les conflits de versions et rend l'ensemble des dépendances reproductible et jetable.
-
Conteneurs de développement : devcontainer.json comme environnement de développement reproductible
Un devcontainer.json décrit le conteneur qu'un éditeur, un espace de travail hébergé dans le cloud ou un exécuteur CI doit construire pour un dépôt : image ou Dockerfile, features, ports redirigés, commandes de cycle de vie et personnalisations d'éditeur. La spécification ouverte de containers.dev rend ce même fichier utilisable en local, dans des espaces de travail hébergés et dans des pipelines, de sorte que la chaîne d'outils est fixée avec le code plutôt que de résider sur chaque hôte.
-
Quels hooks pre-commit survivent un an dans un dépôt d'équipe, et lesquels sont retirés ou régulièrement contournés ?
Question ouverte : le hook pre-commit de Git peut être contourné avec --no-verify, si bien qu'un hook local n'aide que tant que les contributeurs le conservent ; quels types de hooks (formateurs, linters, scanners de secrets, sous-ensembles de tests) sont restés en usage pendant un an ou plus dans des dépôts d'équipe, lesquels ont été retirés ou déplacés vers l'intégration continue, et à quelle fréquence ont-ils été contournés ?
-
Les hooks Git pour des vérifications locales rapides
Les hooks côté client tels que pre-commit exécutent des formateurs et des linters rapides avant même qu'un commit n'existe ; ils font gagner du temps de relecture, mais doivent rester rapides, ne doivent pas être le seul contrôle, et ne sont pas versionnés par Git lui-même.
-
Les exécuteurs de tâches au-delà de make : just, les scripts npm et Invoke pour les commandes de projet
Un exécuteur de tâches donne à un projet un endroit unique pour ses commandes, afin que les personnes, les agents et l'intégration continue invoquent les mêmes noms ; just stocke des recettes dans un justfile avec une syntaxe proche de make et sans logique d'horodatage, les scripts npm vivent dans package.json avec des hooks pre et post, et Invoke transforme des fonctions @task d'un tasks.py en ligne de commande. Choisir celui qui n'exige pas de chaîne d'outils supplémentaire, garder les recettes courtes, et laisser l'intégration continue les appeler.
Lisible par machine : JSON