Factory en pratique : revues de code, tests et refactoring

👁 117 lectures

Factory apporte le plus aux équipes où des tâches de développement importantes attendent en file d’attente, parce qu’il y a toujours quelque chose de plus urgent : revues de code, tests, corrections de bugs mineurs, refactoring de code ancien. Nous avons rassemblé les cas d’usage où les agents Droid déchargent le plus l’équipe.

Nous avons décrit comment installer Droid et configurer la revue de code dans notre tutoriel Factory.

Par où commencer en équipe

La première étape la plus sûre est la revue automatique des pull requests. Elle ne modifie aucun code, ajoute seulement des commentaires, donc l’équipe peut évaluer la qualité du travail de l’agent sans risque. Après deux semaines, vous voyez si les commentaires sont pertinents. La deuxième étape consiste à traiter les bugs mineurs de la liste des tâches en attente, assignés un par un et revus comme les modifications d’un collègue. Seulement ensuite viennent les tâches plus importantes en mode spécification.

Il est important que toute l’équipe connaisse les règles : qui assigne les tâches à l’agent, qui revoit ses modifications et quelles zones du code l’agent ne touche pas sans autorisation.

Revue automatique de chaque pull request

La mise en œuvre la plus simple et souvent la plus perceptible. Droid revoit chaque pull request avant qu’un humain ne le voie, et commente des lignes spécifiques. Il se concentre sur les erreurs, pas sur le style. Le relecteur humain reçoit une modification dont les problèmes évidents ont déjà été détectés, et peut se concentrer sur la logique et l’architecture.

Revue avant soumission

La commande de revue des modifications locales permet au développeur de vérifier le code avant que quiconque ne le voie. Moins de cycles de corrections dans la pull request signifie une fusion plus rapide et moins de changements de contexte entre les tâches.

Corrections de bugs mineurs

Dans chaque projet, il y a une liste de petits bugs que personne n’a le temps de corriger. Vous décrivez le bug, Droid trouve la cause et propose une correction, que vous revoyez comme toute autre modification. La liste en attente diminue sans prendre de temps sur les nouvelles fonctionnalités.

Tests pour du code qui n’en a pas

Les modules plus anciens n’ont souvent pas de tests, donc chaque modification est risquée. Droid écrit des tests pour le code existant, et vous vérifiez s’ils testent ce qui est vraiment important. Après quelques semaines, les modifications dans le code ancien cessent d’être une loterie.

Migrations et changements majeurs avec plan

Mise à jour d’une bibliothèque, changement de structure de base de données, passage à une nouvelle version du langage. Le mode spécification examine d’abord le projet et présente un plan, et l’équipe l’approuve avant la première modification. La documentation Factory recommande ce mode précisément pour les migrations et les changements sensibles à la sécurité.

Tâches dans les scripts et CI

Quand un travail avec Droid fonctionne bien, vous pouvez l’exécuter sans fenêtre interactive, par exemple dans un pipeline CI. Les tâches répétitives, comme la revue ou la génération d’un rapport de modifications, se produisent automatiquement à chaque déploiement.

Travail dans votre éditeur préféré

Droid fonctionne dans VS Code, Cursor, Windsurf, les éditeurs JetBrains et Zed. L’équipe n’a pas besoin de changer d’outils, et dans VS Code l’agent voit le fichier ouvert et les erreurs de l’éditeur.

Exemple : une semaine avec la dette technique

Une équipe de quatre développeurs a sur sa liste trente bugs mineurs et un module de paiement sans tests. Le lundi, elle active la revue automatique des pull requests. Chaque développeur assigne quotidiennement deux bugs mineurs à Droid et revoit les corrections. Le mercredi, ils planifient les tests du module de paiement en mode spécification, et le vendredi ils les fusionnent après revue. La liste des bugs diminue de moitié sans annuler le travail sur la nouvelle fonctionnalité.

L’essentiel est que l’équipe n’a pas annulé le travail sur la nouvelle fonctionnalité. L’agent a pris en charge les tâches qui attendaient de toute façon en file, et les humains se sont occupés de la revue de ses modifications, ce qui prend moins de temps que d’écrire les corrections soi-même. Il vaut la peine de respecter une règle : chaque modification de l’agent a un propriétaire dans l’équipe, qui l’a revue et approuvée. Ainsi, personne ne perd la connaissance de ce qui a changé dans le code.

Points de vigilance

• Revoyez chaque modification de l’agent comme une modification humaine.
• La revue automatique ne remplacera pas un relecteur pour les décisions architecturales.
• Augmentez progressivement l’autonomie de l’agent, quand vous savez comment il se débrouille avec le projet.

Comment vérifier si c’est rentable

Mesurez ce qui fait vraiment mal à l’équipe. Le temps entre l’ouverture d’une pull request et sa fusion, car la revue automatique devrait le réduire. Le nombre de bugs dans la liste des tâches en attente au début et après un mois. La couverture de tests dans les modules qui n’en avaient pas.

Si après un mois aucun de ces chiffres n’a bougé, le problème ne vient généralement pas de l’outil, mais du fait que personne n’a le temps de revoir les modifications de l’agent. Il vaut alors la peine de fixer un moment régulier dans la semaine pour revoir ce qu’il a préparé.

Il vaut aussi la peine de noter quels types de tâches l’agent exécute le mieux. Après un mois, l’équipe sait quoi assigner immédiatement, et quoi mieux faire soi-même, et cesse de perdre du temps à essayer de confier à l’agent des tâches qui nécessitent des connaissances hors du code, par exemple des accords avec le client.

// lire la suiteRay-Ban Meta : combien coûte vraiment une minute d’enregistrement ?MagazineEnfants et chatbots : Meta AI dans Messenger, toujours disponibleMagazineAgents IA bloqués : Amazon, les banques et PSD2Magazine