Directives de Revue de Code

Les revues de code détectent les bugs, partagent les connaissances et améliorent la qualité du code. Les bonnes revues sont collaboratives et éducatives. Les mauvaises revues sont lentes, pointilleuses ou approuvées sans examen. Ce guide couvre les pratiques efficaces de revue de code.

Domaines de Focus de Revue

Processus de Revue

Soumettre des Revues

PROCESSUS DE REVUE DE CODE
══════════════════════════

AVANT DE SOUMETTRE LA PR :
─────────────────────────────────────
L'auteur devrait :
├── Auto-review d'abord
├── Exécuter tests localement
├── Vérifier que linting passe
├── Écrire description claire
├── Lier à l'issue/ticket
├── Garder PR petite (< 400 lignes idéal)
└── PR préparée

DESCRIPTION DE PR :
─────────────────────────────────────
Inclure :
├── Quoi : Résumé des changements
├── Pourquoi : Contexte et motivation
├── Comment : Approche adoptée
├── Tests : Comment ça a été testé
├── Captures : Si changement UI
└── Contexte complet

SÉLECTION REVIEWEUR :
─────────────────────────────────────
├── Expert du domaine
├── Quelqu'un d'externe (regard neuf)
├── Pas toujours la même personne
├── Rotation des revieweurs
├── Équilibrer la charge
└── Bons revieweurs

DÉLAI DE REVUE :
─────────────────────────────────────
├── Demande de revue → Sous 24 heures
├── Feedback traité → Même jour si petit
├── Pas de blocage pendant des jours
├── Attention prioritaire
└── Boucle de feedback rapide

Donner des Revues

Feedback Efficace

DONNER DES REVUES
═════════════════

QUOI RECHERCHER :
─────────────────────────────────────
Haute priorité :
├── Exactitude : Ça fonctionne ?
├── Cas limites : Qu'est-ce qui pourrait casser ?
├── Sécurité : Des vulnérabilités ?
├── Conception : C'est maintenable ?
├── Tests : Les tests sont adéquats ?
└── Problèmes importants

Priorité moindre :
├── Performance (sauf chemin critique)
├── Problèmes de style mineurs
├── Détails pointilleux
├── Préférences personnelles
└── Laissez l'automatisation gérer

COMMENT DONNER DU FEEDBACK :
─────────────────────────────────────
Posez des questions :
├── "Que se passe-t-il si X est null ?"
├── "Avez-vous considéré l'approche Y ?"
├── "Cela pourrait-il être simplifié ?"
└── Ton collaboratif

Expliquez pourquoi :
├── Pas : "Utilisez X au lieu de Y"
├── Mais : "X serait plus clair ici car..."
├── Compréhension, pas ordres
└── Éducatif

Étiquetez le feedback :
├── [Must fix] : Problèmes bloquants
├── [Suggestion] : Améliorations optionnelles
├── [Nit] : Très mineur, non bloquant
├── [Question] : Chercher à comprendre
└── Attentes claires

BON EXEMPLE DE FEEDBACK :
─────────────────────────────────────
"[Suggestion] Considérez extraire cette
logique dans une fonction séparée—cela
faciliterait les tests et rendrait la
fonction principale plus lisible. Heureux
d'en discuter si vous voyez autrement !"

MAUVAIS FEEDBACK :
─────────────────────────────────────
├── "Faux"
├── "Ne faites pas ça"
├── "???"
├── Pas utile, pas clair
└── À éviter

LOUEZ LE BON CODE :
─────────────────────────────────────
├── "Beau refactoring ici !"
├── "Excellente couverture de tests"
├── "Solution astucieuse"
├── La reconnaissance compte
└── Pas que des critiques

Culture de Revue

Dynamiques Saines

CULTURE DE REVUE
════════════════

PRINCIPES :
─────────────────────────────────────
├── Reviewez le code, pas les personnes
├── Supposez les bonnes intentions
├── Collaboratif, pas adversarial
├── Opportunité d'apprentissage
├── Le code de tous est revu
├── Y compris les seniors
└── Culture saine

ÉVITER :
─────────────────────────────────────
├── Pinailler sur détails mineurs
├── Exiger préférences de style
├── Bloquer pour raisons triviales
├── Être impoli ou condescendant
├── Approuver sans examen (rubber-stamp)
├── Prendre les critiques personnellement
└── Anti-patterns

RÉSOUDRE LES DÉSACCORDS :
─────────────────────────────────────
├── Discuter en synchrone si bloqué
├── Focus sur le code, pas l'ego
├── Escalader si nécessaire
├── Accepter quand vous avez tort
├── Passer à autre chose
└── Résolution professionnelle

AUTOMATISATION :
─────────────────────────────────────
Laissez les outils gérer :
├── Formatage (Prettier, Black)
├── Linting (ESLint, Pylint)
├── Vérification de types
├── Exécution des tests
├── Scan de sécurité
├── Humains focus sur logique
└── Utilisation efficace du temps

Intégration GitScrum

Lier Revues au Travail

GITSCRUM POUR LES REVUES
════════════════════════

LIAISON DE TÂCHES :
─────────────────────────────────────
├── Lier PR à tâche GitScrum
├── Mettre à jour statut tâche
├── Traçabilité
├── Quoi livré quand
└── Workflow connecté

DÉFINITION DU DONE :
─────────────────────────────────────
DoD inclut :
├── ☐ PR soumise
├── ☐ Code revu
├── ☐ Feedback traité
├── ☐ Approuvée
├── ☐ Mergée
└── Revue requise

MÉTRIQUES DE REVUE :
─────────────────────────────────────
Suivre :
├── Temps de revue
├── Profondeur de revue
├── Cycles de révision
├── Identifier goulots
└── Amélioration processus

Meilleures Pratiques

Pour les Revues de Code

1. Revues rapides — Sous 24 heures
2. Petites PR — Plus faciles à bien reviewer
3. Ton constructif — Questions plutôt qu'exigences
4. Focus sur le fond — Pas sur détails de style
5. Automatiser le style — Humains reviewent la logique

Anti-Patterns

ERREURS DE REVUE :
✗ Prendre des jours pour reviewer
✗ PR géantes
✗ Approuver sans examen
✗ Pinailler sur le style
✗ Commentaires condescendants
✗ Pas d'explications
✗ Bloquer trivialement
✗ Ne jamais louer

Solutions Connexes

• Meilleures pratiques d'intégration continue
• Suivi de la qualité du code
• Pratiques de pair programming