Réception de Code Review

Vue d'ensemble

La code review demande une évaluation technique, non une performance émotionnelle.

Principe fondamental : Récupérer le feedback → Vérifier → Implémenter → Re-tester → Pousser les mises à jour.

Annoncer au départ : « J'utilise la skill Nori Receiving Code Review pour traiter ce feedback. »

Le processus

Étape 0 : Créer une liste de tâches

Pour un feedback multi-éléments, utiliser TodoWrite :

- [ ] Récupérer et lire tous les commentaires de PR
- [ ] Clarifier les éléments ambigus (le cas échéant)
- [ ] Corriger l'élément 1 : [description]
- [ ] Corriger l'élément 2 : [description]
...
- [ ] Exécuter tests/lint/format
- [ ] Pousser les mises à jour

Pourquoi : Prévient les oublis et offre de la visibilité à l'utilisateur.

Étape 1 : Récupérer les commentaires de PR

Déterminer le numéro de PR à partir du contexte :

• L'utilisateur mentionne le numéro de PR : Utiliser celui-ci
• Branche courante : Exécuter gh pr view --json number -q .number

Récupérer tous les commentaires :

# Afficher tous les commentaires (review + généraux)
gh pr view [PR-NUMBER] --comments

Lire complètement avant de réagir.

Étape 2 : Comprendre et clarifier

Appliquer ces vérifications à chaque élément :

• [ ] Puis-je reformuler cette exigence avec mes propres mots ?
• [ ] Est-ce techniquement valide pour CETTE base de code ?
• [ ] Cela casse-t-il les fonctionnalités existantes ?
• [ ] Y a-t-il une raison à l'implémentation actuelle ?

CRITIQUE : Si UN SEUL élément est ambigu, ARRÊTER. Demander une clarification sur TOUS les éléments ambigus avant d'implémenter QUOI QUE CE SOIT.

Exemple :

Utilisateur : « Corriger les éléments 1-6 »
Tu comprends 1,2,3,6. Ambigu sur 4,5.

✅ « Comprends 1,2,3,6. Besoin de clarification sur 4 et 5 avant d'implémenter. »
❌ Implémenter 1,2,3,6 maintenant, poser des questions sur 4,5 plus tard

Étape 3 : Implémenter les changements

Suivre l'ordre d'implémentation :

1. Problèmes bloquants (cassures, sécurité)
2. Corrections simples (typos, imports)
3. Corrections complexes (refactoring, logique)

Pour chaque correction :

• [ ] Implémenter un à la fois
• [ ] Tester individuellement
• [ ] Committer individuellement (commits fréquents)

Vérification YAGNI : Si le reviewer suggère « implémenter correctement », faire un grep pour l'usage réel :

grep -r "endpointName" .

Si inutilisé : « Cet endpoint n'est pas appelé. Le supprimer (YAGNI) ? »

Étape 4 : Exécuter tests, lint et format

Référence finishing-a-development-branch skill (Étapes 1-2) :

Voir .claude/skills/finishing-a-development-branch/SKILL.md

• [ ] Exécuter tests : npm test (ou équivalent du projet)
  • Si les tests échouent, corriger avant de continuer
• [ ] Exécuter vérifications de types : npm run lint:*-types (si disponible)
  • Si erreurs de types, corriger avant de continuer
• [ ] Exécuter formatter : npm run format
• [ ] Exécuter linter : npm run lint
• [ ] Vérifier changements : git diff --stat

Étape 5 : Pousser les mises à jour

Pousser les changements à la PR :

git push

Étape 6 : Résumé et prochaine action

Signaler ce qui a changé :

« Feedback de code review adressé :

• Corrigé [élément 1] : [description brève]
• Corrigé [élément 2] : [description brève] ...

Changements poussés à la PR. Options :

1. Fait - La PR est prête pour re-review
2. Plus de feedback - Des changements supplémentaires sont nécessaires
3. Afficher changements - Examiner les diffs avant de marquer comme fait

Que préfères-tu ? »

Checklist de référence rapide

• [ ] Créer TodoWrite pour tous les éléments de feedback
• [ ] Récupérer commentaires de PR (gh pr view --comments)
• [ ] Clarifier TOUS les éléments ambigus avant d'implémenter UN SEUL
• [ ] Implémenter dans l'ordre : bloquant → simple → complexe
• [ ] Tester chaque correction individuellement
• [ ] Exécuter tests, vérifications de types, formatting, linting (finishing-a-development-branch)
• [ ] Pousser les mises à jour
• [ ] Résumer les changements et demander la prochaine action

Directives de ton de réponse

Interdites :

• « Vous avez tout à fait raison ! » / « Bon point ! » / « Merci pour... » (accord performatif)
• Implémenter avant de vérifier par rapport à la base de code
• Procéder avec un feedback ambigu

Requises :

• Vérifier les suggestions contre la réalité de la base de code avant d'implémenter
• Repousser avec un raisonnement technique si la suggestion casse quelque chose ou viole YAGNI
• Demander une clarification sur TOUS les éléments ambigus avant d'implémenter UN SEUL élément
• Énoncer les corrections factuellement : « Corrigé. [ce qui a changé] » ou simplement afficher le code

Vérification YAGNI : Si le reviewer suggère « implémenter correctement », faire un grep pour l'usage réel. Si inutilisé, demander : « Cet endpoint n'est pas appelé. Le supprimer (YAGNI) ? »

Quand tu avais tort après avoir repoussé : « Tu avais raison - j'ai vérifié [X] et c'est [Y]. J'implémente maintenant. » Aucune excuse nécessaire.

Reviewers externes : Vérifier que c'est techniquement correct pour CETTE base de code, fonctionne sur toutes les plateformes, ne conflicte pas avec les décisions antérieures du partenaire. Si conflits, en discuter d'abord avec le partenaire.

Signal d'inconfort en repoussant : « Strange things are afoot at the Circle K »

Erreurs courantes

Signaux d'alerte

Ne jamais :

• Ignorer la création de TodoWrite pour un feedback multi-éléments
• Implémenter sans vérifier par rapport à la base de code
• Procéder avec un feedback ambigu
• Ignorer tests/linting/formatting avant de pousser

Toujours :

• Lire tout le feedback complètement en premier
• Clarifier les éléments ambigus avant d'implémenter
• Tester chaque correction individuellement
• Exécuter une vérification complète avant de pousser
• Fournir un résumé des changements à l'utilisateur