Optimisation Revue de Code | GitScrum
Transformez les revues de code en accélérateurs. GitScrum suit le statut et identifie les retards de revue.
6 min de lecture
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 │
└─────────────────────────────────────────────────────────────┘