Revue de code

Lorsque vous confiez à Claude Code une tâche à accomplir dans votre base de code, Claude rend généralement compte de manière succincte. Sous la description de ce que Claude a modifié, il peut y avoir divers fichiers modifiés (allant de changements mineurs à des changements majeurs). Bien souvent, la session qui a écrit les modifications de code elle-même (et les a expliquées) n'est pas le meilleur juge de ces modifications. C'est une bonne pratique d'examiner vous-même chaque modification avant de la conserver, puis de demander à Claude de la revoir à nouveau depuis un contexte propre, sans l'historique de cette session.

Examiner les modifications réelles

Un diff représente l'avant et l'après d'une modification : les lignes supprimées et les lignes ajoutées, fichier par fichier. La commande /diff ouvre un visualiseur interactif de vos modifications non validées sous cette forme, et elle peut également afficher ce que chaque tour de Claude a modifié. Utilisez les flèches haut et bas pour naviguer entre les fichiers et Enter pour en ouvrir un.

Les éléments les plus importants qui méritent systématiquement un second regard sont :

• Les modifications que vous n'avez pas demandées. Une valeur de configuration modifiée pendant que Claude était dans le fichier, ou une méthode utilitaire réécrite que vous n'aviez pas mentionnée.
• Les tests affaiblis. Si le projet sur lequel vous travaillez contient des tests, identifiez ceux qui ont été ignorés, supprimés ou assouplis jusqu'à ce qu'ils passent.
• Les nouveaux paquets et les valeurs codées en dur. Une dépendance ajoutée pour une seule fonction, une URL ou une clé écrite directement dans le code.

Si l'ensemble de la modification est erroné, exécutez /rewind (ou appuyez deux fois sur Esc sur une invite vide), sélectionnez l'invite qui l'a produite, puis choisissez Restaurer le code et la conversation. Une limite à connaître : les fichiers modifiés par des commandes shell exécutées par Claude, comme l'installation d'un paquet, ne sont pas annulés.

L'exercice ci-dessous utilise une petite tâche de formulaire d'inscription : le résumé de Claude en haut, les huit fichiers que Claude a modifiés en dessous.

Demander un second avis

La leçon Explorer → Planifier → Coder → Valider indiquait qu'il fallait faire appel à un second relecteur pour une modification avant de la valider. Une longue session conserve tout ce qu'elle a lu et décidé. C'est le contexte que vous avez appris à gérer dans la leçon précédente, et c'est précisément l'historique que vous ne voulez pas voir chez un relecteur. /code-review est ce second relecteur : il examine la modification dans un contexte propre, sans aucun historique de votre session, et rapporte ce qu'il trouve. Il ne modifie rien à moins que vous ne le lui demandiez.

La revue s'exécute en arrière-plan, de quelques secondes à quelques minutes, et elle est comptabilisée dans votre utilisation comme toute autre tâche, réservez-la donc aux modifications qui méritent un second regard. Les résultats arrivent dans votre conversation une fois la revue terminée. Vous pouvez également le demander en termes simples, et Claude peut lancer la même revue à partir de cette demande. Si Claude répond directement au lieu de lancer une revue, exécutez vous-même la commande.

Pour la modification du formulaire d'inscription, la revue a renvoyé quatre résultats :

Décider quoi faire de chaque résultat

Classez chaque résultat dans l'une des trois catégories suivantes :

1. À corriger maintenant. Il s'agit d'un problème réel, important, qui doit être corrigé.
2. À questionner. C'est la catégorie pour les résultats que vous ne pouvez pas tout à fait vérifier ou qui semblent étranges. Il est possible que les relecteurs qui examinent des modifications de code à froid passent eux aussi à côté de certaines choses.
3. À laisser de côté. Il s'agit d'un problème réel mais mineur ou sans conséquence. Ces problèmes peuvent souvent être regroupés dans un lot de corrections que vous traiterez lors d'une future session.

Pour questionner un résultat, citez-le à Claude et demandez-lui de vérifier à nouveau. Pour le deuxième résultat ci-dessus, vous taperiez :

Chaque fois que vous demandez une correction, il est bon de demander également des preuves :

Si une correction finit par devenir une modification importante à part entière, relancez la revue.

Quand il est payant d'examiner les choses de plus près

Une modification simple d'une seule ligne ne nécessite souvent qu'un coup d'œil rapide au diff, rien de plus. Vous devriez recourir à une revue humaine et à une revue de Claude lorsqu'une modification est trop importante pour être gardée entièrement en tête, lorsqu'elle touche à quelque chose de sensible ou effectue une action destructrice, et avant de transmettre le travail à un coéquipier.

Essayez : classez les quatre résultats

Récapitulatif

• Lisez le diff réel des modifications de fichiers avant de faire confiance au seul résumé. Exécutez /diff et recherchez les modifications que vous n'avez pas demandées, les tests affaiblis, ainsi que les nouveaux paquets ou valeurs codées en dur.
• Obtenez un second avis depuis un contexte propre avec /code-review (ou demandez-le en termes simples et laissez Claude le lancer). Le relecteur rapporte ses résultats, et Claude ne modifie rien à moins que vous ne le demandiez.
• Traitez chaque résultat comme « à corriger maintenant », « à questionner » ou « à laisser de côté », et demandez des preuves pour chaque correction.

Lorsque le relecteur signale le même problème à plusieurs reprises, il peut être judicieux d'écrire une règle que Claude lira au début de chaque session. Ce fichier est CLAUDE.md, et c'est le sujet de la prochaine leçon.