6 min lecture • Guide 81 of 877
Réviser du Code Efficacement
Les revues de code peuvent être un goulot d'étranglement ou un multiplicateur de force. Les revues efficaces améliorent la qualité du code, diffusent les connaissances et détectent les bugs tôt. Les mauvaises revues créent des frictions, retardent le travail et nuisent au moral de l'équipe. GitScrum s'intègre avec GitHub/GitLab pour rendre les revues visibles et efficaces.
Objectifs de la Revue de Code
| Objectif | Comment Atteindre |
|---|---|
| Trouver les bugs | Focus sur la logique, cas limites |
| Diffuser les connaissances | Revoir à travers les spécialités |
| Améliorer le design | Discuter l'architecture |
| Maintenir les standards | Style cohérent, patterns |
| Mentorer | Expliquer le raisonnement |
Processus de Revue
Meilleures Pratiques de Soumission
CHECKLIST AUTEUR PR
═══════════════════
AVANT DE SOUMETTRE :
- [ ] Auto-reviewé le diff
- [ ] Tests passent localement
- [ ] Linter passe
- [ ] Pas de code debug
- [ ] Description explique le pourquoi
BONNE DESCRIPTION PR :
─────────────────────────────────────
## Quoi
Description brève du changement.
## Pourquoi
Contexte et motivation.
## Comment
Approche technique choisie.
## Tests
Comment cela a été vérifié.
## Screenshots (si UI)
Avant/après si applicable.
## Lié
Liens vers tâche GitScrum, docs, etc.
─────────────────────────────────────
Guidelines de Taille PR
RECOMMANDATIONS TAILLE PR
═════════════════════════
IDÉAL : 50-200 lignes modifiées
ACCEPTABLE : 200-400 lignes modifiées
TROP GROS : 400+ lignes modifiées
POURQUOI PETITES PR :
├── Plus faciles à reviewer en profondeur
├── Turnaround plus rapide
├── Moins de risque par changement
├── Plus simples à reverter
└── Meilleur transfert de connaissances
STRATÉGIES DE DÉCOUPAGE :
├── Feature flags pour travail partiel
├── Extraire le refactoring séparément
├── Séparer tests de l'implémentation
├── Infrastructure vs logique
└── Backend vs frontend
Processus Reviewer
WORKFLOW DE REVUE
═════════════════
PHASE 1 : COMPRENDRE (5 min)
├── Lire la description PR
├── Vérifier le contexte de la tâche liée
├── Comprendre l'objectif
└── Revoir le plan de test
PHASE 2 : HAUT NIVEAU (10 min)
├── L'approche est-elle bonne ?
├── Préoccupations architecturales ?
├── Composants manquants ?
└── Scope correct ?
PHASE 3 : DÉTAILLÉ (15-30 min)
├── Correction logique
├── Cas limites gérés
├── Gestion des erreurs
├── Implications performance
├── Considérations sécurité
└── Couverture de tests
PHASE 4 : RÉPONDRE (5 min)
├── Organiser le feedback
├── Prioriser les commentaires
├── Approuver, demander changements, ou commenter
└── Être réactif aux questions
Framework de Feedback
Types de Commentaires
CLASSIFICATION DES COMMENTAIRES
═══════════════════════════════
BLOQUANT (doit corriger) :
├── Bugs et erreurs de logique
├── Vulnérabilités de sécurité
├── Tests critiques manquants
├── Breaking changes
└── Viole les patterns core
NON-BLOQUANT (à considérer) :
├── Suggestions de performance
├── Approches alternatives
├── Améliorations mineures
├── Préférences de style (au-delà du linter)
└── Nice-to-have
ÉLOGE (important !) :
├── Solutions ingénieuses
├── Bonne couverture de tests
├── Refactoring propre
├── Bonne documentation
└── Moments d'apprentissage
FORMAT :
─────────────────────────────────────
[bloquant] Ceci va échouer si user est null
[nit] Envisager de renommer en `isValidUser`
[éloge] Super gestion du cas limite !
─────────────────────────────────────
Feedback Constructif
EXEMPLES DE FEEDBACK
════════════════════
AU LIEU DE : ESSAYER :
───────────────────────────────────────────────────
"C'est faux" "Ceci pourrait causer X
parce que Y. Considère Z."
"Pourquoi tu n'as pas... ?" "Est-ce que ça aiderait de... ?"
"C'est confus" "J'ai du mal à suivre
ceci. Tu pourrais ajouter
un commentaire ou renommer
cette variable ?"
"Refais" "Cette approche a X problème.
Voici une alternative..."
FORMULE DE FEEDBACK :
─────────────────────────────────────
Observation + Impact + Suggestion
"Cette query dans une boucle [observation]
va causer N+1 requêtes [impact].
Envisage le eager loading [suggestion]."
Métriques et Optimisation
Suivre la Performance
MÉTRIQUES DE REVUE
══════════════════
OBJECTIFS :
├── Première réponse : < 4 heures
├── Temps avant merge : < 24 heures
├── Tours de revue : 1-2 max
└── Taille PR : < 400 lignes
TABLEAU DE BORD :
┌─────────────────────────────────────────────────────────────┐
│ REVUES CETTE SEMAINE │
│ │
│ PR créées : 18 │
│ Temps moy. 1ère réponse : 3.5h ✓ │
│ Temps moy. merge : 16h ✓ │
│ Tours moyens : 1.3 ✓ │
│ PR > 48h : 1 ⚠ │
│ │
│ PAR REVIEWER : │
│ @alex : 6 revues, 2.1h moy │
│ @marie : 5 revues, 3.8h moy │
│ @chen : 7 revues, 4.2h moy │
└─────────────────────────────────────────────────────────────┘
Équilibrer la Charge
DISTRIBUTION DES REVUES
═══════════════════════
OBJECTIF : Distribution équitable
├── Éviter les goulets (1 reviewer surchargé)
├── Diffuser les connaissances
├── Développer les juniors
└── Éviter le burnout
STRATÉGIES :
├── Code Owners par domaine
├── Rotation des reviewers
├── Pair avec junior + senior
├── Limites de revues par personne/jour
└── Automatisation de l'assignation
Meilleures Pratiques
Règles d'Or
- Revoyez rapidement : Première réponse en < 4h
- Automatisez le trivial : Style = linter, pas humain
- Soyez spécifique : Expliquez le problème et proposez une solution
- Soyez respectueux : Code, pas la personne
- Petites PR : Plus faciles, plus rapides, meilleures
- Apprenez aussi : La revue est bidirectionnelle