Réviser efficacement les diffs d’un agent

Le code d’un agent est fluide. Bien nommé, formaté de façon constante, commenté avec assurance : facile à survoler et à approuver. C’est justement le piège.

Tout lire de haut en bas ne tient pas la route non plus. Ce qui marche pour moi, c’est un ordre fixe qui met mon attention là où se trouve le risque.

Lisez dans cet ordre, pas dans l’ordre des fichiers

La passe de revue

1. 1

   1 min

   Résumé vs brief

   Lisez le résumé final de l’agent à côté de votre brief. Ce qu’il dit ne pas avoir fait, ou avoir fait en plus, vous indique où regarder en premier.

2. 2

   1 min

   Vérifier la portée

   Regardez la liste des fichiers modifiés et le nombre de lignes avant tout code. Les fichiers inattendus sont la première question à régler.

3. 3

   3 min

   Les tests d’abord

   Un test existant a-t-il changé? Les nouveaux tests vérifient-ils un vrai comportement, avec des valeurs attendues que vous auriez écrites vous-même?

4. 4

   3 min

   Interfaces et contrats

   Signatures publiques, migrations de base de données, config, dépendances, gestion d’erreurs aux frontières. Les erreurs ici se propagent.

5. 5

   5+ min

   Logique centrale

   Les quelques fonctions où la vraie décision se prend. Lisez-les ligne par ligne et exécutez le code en cas de doute.

6. 6

   1 min

   Changements mécaniques

   Renommages, imports, fichiers générés, formatage. Survolez pour repérer ce qui n’est pas mécanique et qui s’y cache.

Faites-vous remettre une carte

L’agent sait quelles parties de son changement étaient délicates. Demandez-lui de le dire, à la fin de chaque exécution.

Avant de terminer, donne-moi un guide de revue :
1. Les fichiers modifiés, groupés en : logique centrale / tests /
   interfaces / mécanique.
2. Tout test existant que tu as modifié, et pourquoi.
3. Les décisions que tu as prises et que je n'avais pas précisées.
4. Ce que tu n'as PAS vérifié, et ce dont tu n'es pas sûr.

Les signaux d’alarme qui méritent un arrêt

Retournez chaque carte. Ce sont les motifs sur lesquels je m’arrête pour poser des questions, peu importe à quel point le reste du diff est propre.

🃏 Signaux d’alarme dans un diff

Touchez une carte pour la retourner

Une valeur attendue a changé dans un test existantSoit l’exigence a changé, soit le test a été plié pour coller au code. Vous seul savez lequel. Demandez avant d’accepter.Une nouvelle dépendance est apparueLa tâche en avait-elle besoin? Est-elle maintenue, bien licenciée, déjà couverte par quelque chose dans le dépôt? Les dépendances survivent à la tâche.Un bloc catch qui journalise et continueDes erreurs avalées pour faire passer un flux. Vérifiez ce que l’appelant devrait vraiment voir quand ça échoue.Du code supprimé parce qu’« inutilisé »Inutilisé selon la recherche de l’agent, peut-être. La réflexion, la config, les autres services et les scripts n’apparaissent pas toujours dans une recherche.Des valeurs codées en dur qui correspondent aux données de testLe code traite peut-être les données de test comme cas spécial au lieu d’implémenter la règle. Essayez une valeur que les tests n’utilisent pas.La config de CI, de build ou du linter a été modifiéeChanger les règles du jeu fait rarement partie de la tâche. Traitez-le comme un changement à part, révisé séparément.

La revue du code d’agent en équipe, avec la propriété du code et les approbations, est un sujet en soi. On le couvre au module 6.

Avant de continuer

✅ À retenir

0 / 4 complété

• Je lis le résumé et la liste des fichiers avant tout code.
• Je révise les tests avant l’implémentation et je vérifie si des tests existants ont changé.
• Je mets l’essentiel de mon attention sur les interfaces et la logique centrale, et je survole les changements mécaniques.
• Mes briefs demandent un guide de revue à l’agent, et je le traite comme une carte, pas comme un verdict.

↺ Réinitialiser