Kevin Murphy partage sa méthode pour lire et évaluer les demandes de pull request (PR). Il explique quand il préfère les examiner (au début ou à la fin de la journée, entre les réunions, etc.), ce qu'il cherche (le but de la PR, son état d'avancement), pourquoi il les examine (demande explicite, expertise, désir d'apprendre) et comment il adapte son approche en fonction de l'auteur. Son objectif est d'aider à faire avancer le travail vers la production, de partager des connaissances et de stimuler la réflexion.
Comment bien scaler les code reviews (et éviter les pièges)
À l’origine, une petite équipe peut se permettre de merger directement dans la branche principale, mais dès que le projet grandit, les code reviews deviennent essentielles pour maintenir la qualité du code. Pourtant, mal gérées, elles ralentissent les équipes (délais serrés, feedbacks sur des détails mineurs), génèrent des conflits (préférences personnelles, ton toxique) et favorisent les incompréhensions (revues asynchrones, PR trop volumineuses). Pour y remédier, auteurs et relecteurs doivent adopter des bonnes pratiques : PR petites et ciblées, feedback constructif et documenté, respect du temps de chacun (réponse sous 24h, slots dédiés), et automatisation (CI, outils comme CodeRabbit pour les checks routiniers). L’objectif ? Améliorer la qualité sans bloquer la vélocité : privilégier le "bon assez" plutôt que la perfection, utiliser des checklists, et résoudre les désaccords en direct. Les outils modernes (GitHub/GitLab, AI comme CodeRabbit) optimisent le workflow en détectant les bugs tôt et en résumant les changements, libérant les humains pour des revues plus stratégiques. En résumé : des revues rapides, bienveillantes et outillées pour un code sain et des équipes motivées.
L’article relate l’expérience d’un ingénieur utilisant Claude Code pour automatiser des tâches de développement (refactoring, correction de bugs, écriture de tests). Si l’outil excelle pour des corrections ponctuelles, il génère souvent des PRs volumineuses et illisibles, rendant la revue de code difficile. La solution trouvée : apprendre à Claude à structurer son travail en "stacked PRs" (séries de petites PRs ciblées et indépendantes), comme le feraient des humains expérimentés. En guidant l’IA avec des instructions précises et en utilisant l’outil GT MCP de Graphite, l’auteur parvient à obtenir des PRs claires, testables et faciles à relire. Résultat : une intégration plus fluide de l’IA dans le workflow, permettant de construire des fonctionnalités complètes, de corriger des bugs complexes et d’ajouter des tests, tout en gardant un code maintenable et collaboratif.
Tout est dans le titre
Suite de l'article précédent, l'auteur montre la procédure courante pour fusionner une branche dans un dépôt public, via une pull request.
Tout est dans le titre
Tout est dans le titre
un workflow intéressant
Tout est dans le titre
Tout est dans le titre