6 min lecture • Guide 654 of 877
Optimisation du Processus de Revue de Code
Les revues de code sont cruciales pour la qualité du code et le partage des connaissances, mais de mauvais processus créent des goulots d'étranglement frustrants. GitScrum aide à suivre le statut des revues, identifier les retards de revue et mesurer les temps de réponse pour aider les équipes à optimiser leurs workflows de revue.
Conception du Processus de Revue
Étapes du Workflow
PIPELINE DE REVUE DE CODE :
┌─────────────────────────────────────────────────────────────┐
│ │
│ PR CRÉÉE → PRÊTE POUR REVUE → EN REVUE → APPROUVÉE │
│ │ │ │ │
│ ▼ ▼ ▼ │
│ [Attente] [Active] [Merge] │
│ Cible: <4h Cible: <24h Cible: <2h │
│ │
├─────────────────────────────────────────────────────────────┤
│ │
│ ÉTAT ACTUEL : │
│ Prêt pour Revue : 3 PRs (plus vieille : 2h) ✅ Sain │
│ En Revue : 2 PRs ✅ Sain │
│ Approuvée : 1 PR (attend merge) ✅ Sain │
│ │
│ ALERTES : │
│ ⚠️ PR #234 attend 6h (SLA dépassé) │
│ │
└─────────────────────────────────────────────────────────────┘
SLA de Revue
ATTENTES DE REVUE :
┌─────────────────────────────────────────────────────────────┐
│ │
│ PRIORITÉ │ 1ÈRE RÉPONSE │ COMPLÉTION │ ESCALADE │
│─────────────┼────────────────┼────────────┼────────────────│
│ Critique │ 2 heures │ 4 heures │ Après 3h │
│ Haute │ 4 heures │ 24 heures │ Après 6h │
│ Normale │ 24 heures │ 48 heures │ Après 36h │
│ Basse │ 48 heures │ 72 heures │ Après 60h │
│ │
│ TYPES DE RÉPONSE : │
│ • Approuver : Prêt à merger │
│ • Commenter : Questions/suggestions (non bloquant) │
│ • Demander Modifs : Doit traiter avant merge │
│ │
│ QUAND DEMANDER DES MODIFICATIONS : │
│ • Vulnérabilités de sécurité │
│ • Breaking changes sans migration │
│ • Tests manquants pour chemins critiques │
│ • Bugs clairs dans la logique │
└─────────────────────────────────────────────────────────────┘
Meilleures Pratiques de Pull Request
Directives de Taille de PR
TAILLE OPTIMALE DE PR :
┌─────────────────────────────────────────────────────────────┐
│ │
│ LIGNES │ TEMPS REVUE │ QUALITÉ │ RECOMMANDATION │
│──────────┼──────────────┼────────────┼─────────────────────│
│ <100 │ 15-30 min │ Excellente │ ✅ Idéal │
│ 100-400 │ 30-60 min │ Bonne │ ✅ Acceptable │
│ 400-800 │ 60-90 min │ Déclinante │ ⚠️ Considérez split │
│ 800+ │ 90+ min │ Mauvaise │ ❌ Trop grande │
│ │
│ STRATÉGIES POUR DES PR PLUS PETITES : │
│ │
│ 1. Feature flags │
│ Livrer fonctionnalités incomplètes derrière flags │
│ │
│ 2. PR empilées │
│ PR 1: Modèle data → PR 2: API → PR 3: UI │
│ │
│ 3. Extraire le refactoring │
│ Refactorer d'abord, fonctionnalité ensuite │
│ │
│ 4. Tranches verticales │
│ Livrer fonctionnalité mince bout en bout │
└─────────────────────────────────────────────────────────────┘
Template de Description PR
TEMPLATE PR :
┌─────────────────────────────────────────────────────────────┐
│ ## Quoi │
│ [Description en une ligne du changement] │
│ │
│ ## Pourquoi │
│ [Contexte : problème résolu, lien vers tâche] │
│ │
│ ## Comment │
│ [Approche technique brève, décisions clés] │
│ │
│ ## Tests │
│ - [ ] Tests unitaires ajoutés/mis à jour │
│ - [ ] Tests manuels complétés │
│ - [ ] Cas limites considérés │
│ │
│ ## Captures d'écran (si changement UI) │
│ [Captures Avant/Après] │
│ │
│ ## Focus de Revue │
│ [Sur quoi vous aimeriez que les revieweurs se concentrent] │
│ │
│ ## Checklist │
│ - [ ] Auto-review effectuée │
│ - [ ] Tests passent │
│ - [ ] Documentation mise à jour │
└─────────────────────────────────────────────────────────────┘
Efficacité des Revues
Automatisation d'Abord
VÉRIFICATIONS AUTOMATISÉES (avant revue humaine) :
┌─────────────────────────────────────────────────────────────┐
│ │
│ PIPELINE CI : │
│ ✓ Lint - Vérifications de style │
│ ✓ Type check - Erreurs TypeScript │
│ ✓ Tests unitaires - Suite de tests automatisée │
│ ✓ Build - Compilation réussit │
│ ✓ Scan sécurité - Vulnérabilités connues │
│ │
│ BÉNÉFICE : Humains reviewent logique, pas formatage │
│ │
│ CODEOWNERS : │
│ # Assigner automatiquement revieweurs par chemin │
│ /api/* @equipe-backend │
│ /frontend/* @equipe-frontend │
│ /security/* @equipe-securite │
│ *.sql @equipe-dba │
│ │
│ COMMENTAIRES BOT : │
│ • Rapport de couverture │
│ • Changement taille bundle │
│ • Impact performance │
└─────────────────────────────────────────────────────────────┘
Réunions de Revue
REVUE EN BINÔME :
┌─────────────────────────────────────────────────────────────┐
│ │
│ QUAND REVIEWER EN BINÔME (sync) : │
│ • Changements architecturaux complexes │
│ • Code sensible en sécurité │
│ • PR de développeur junior (opportunité enseignement) │
│ • Dépendances inter-équipes │
│ │
│ QUAND L'ASYNC EST OK : │
│ • Petites PR bien documentées │
│ • Patterns standards │
│ • Corrections de bugs avec tests clairs │
│ │
│ HEURE DE REVUE (Pratique d'Équipe) : │
│ Quotidien 14h-15h : Équipe revoit les PR en attente │
│ │
│ Bénéfices : │
│ • Les PR ne vieillissent pas │
│ • Partage de connaissances │
│ • Qualité de revue cohérente │
└─────────────────────────────────────────────────────────────┘