GitScrum
Essayer gratuitement
7 min lecture • Guide 190 of 877

Améliorer les Processus de Revue de Code

La revue de code est essentielle pour la qualité mais devient souvent un goulot d'étranglement. Les revues lentes bloquent le travail, les retours peu clairs causent de la frustration, et les standards incohérents font perdre du temps. Améliorer la revue de code nécessite des solutions techniques, des directives claires et un changement culturel.

Problèmes de Revue de Code

ProblèmeSolution
Revues prennent des joursSLA de revue + PR plus petites
Retours pointilleuxAutomatiser les vérifications de style
Standards peu clairsDirectives écrites
Revues conflictuellesCode de conduite
Goulot de reviewersPlus de reviewers + rotation

Directives de Revue

Quoi Réviser

DOMAINES DE FOCUS REVUE DE CODE
════════════════════════════════

HAUTE PRIORITÉ (revue humaine):
─────────────────────────────────────
✓ CORRECTION
  ├── Fait-il ce qu'il devrait?
  ├── Cas limites gérés?
  ├── Gestion d'erreurs correcte?
  └── Défauts de logique?

✓ DESIGN
  ├── Bon niveau d'abstraction?
  ├── Respecte l'architecture?
  ├── Maintenable?
  └── Extensible?

✓ SÉCURITÉ
  ├── Vulnérabilités d'injection?
  ├── Authentification/autorisation?
  ├── Exposition de données sensibles?
  └── Validation des entrées?

✓ TESTS
  ├── Tests couvrent les changements?
  ├── Cas limites testés?
  ├── Tests lisibles?
  └── Tests maintenables?

AUTOMATISER (pas revue humaine):
─────────────────────────────────────
✗ Formatage
✗ Conventions de style
✗ Ordre des imports
✗ Variables inutilisées
✗ Erreurs de type
✗ Patterns de bugs courants
└── Tout géré par linters/CI

Taille des PR

BONNES PRATIQUES TAILLE PR:
════════════════════════════

IDÉAL: < 200 lignes de code changé

TEMPS DE REVUE PAR TAILLE:
┌─────────────────────────────────────────────────────────────┐
│ Taille PR      │ Temps Revue │ Qualité Revue              │
├─────────────────────────────────────────────────────────────┤
│ < 100 lignes   │ 15-30 min   │ ★★★★★ Excellente           │
│ 100-200 lignes │ 30-60 min   │ ★★★★☆ Très bonne           │
│ 200-400 lignes │ 1-2 heures  │ ★★★☆☆ Acceptable           │
│ 400-800 lignes │ 2-4 heures  │ ★★☆☆☆ Fatigue s'installe   │
│ > 800 lignes   │ > 4 heures  │ ★☆☆☆☆ Superficielle        │
└─────────────────────────────────────────────────────────────┘

STRATÉGIES POUR PETITES PR:
├── Découper en commits logiques
├── Feature flags pour livraison incrémentale
├── Séparer refactoring du nouveau code
├── Une PR = un concept
└── Si trop grand: stacked PRs

Accélérer les Revues

SLA de Revue

DÉFINIR DES DÉLAIS:
════════════════════

SLA ÉQUIPE RECOMMANDÉ:
┌─────────────────────────────────────────────────────────────┐
│                                                             │
│ PREMIER FEEDBACK: < 4 heures ouvrées                       │
│                                                             │
│ APPROBATION (si pas de changements majeurs): < 1 jour      │
│                                                             │
│ ITÉRATIONS: < 4 heures par round                           │
│                                                             │
│ MAXIMUM TOTAL: 2 jours ouvrés                              │
│                                                             │
└─────────────────────────────────────────────────────────────┘

PRIORISATION:
├── Revue avant de commencer du nouveau code
├── Notifications de PR = haute priorité
├── Bloquer les revues = bloquer l'équipe
└── Reviewer = aussi important que coder

MÉTRIQUES À SUIVRE:
├── Temps première réponse
├── Temps jusqu'à approbation
├── Nombre de rounds
└── Tendance par semaine

Rotation des Reviewers

SYSTÈME DE ROTATION:
═════════════════════

PROBLÈME:
Alice fait 80% des revues → Goulot

SOLUTION - ROTATION:
┌─────────────────────────────────────────────────────────────┐
│ Semaine │ Reviewer Principal │ Backup                      │
├─────────────────────────────────────────────────────────────┤
│ S1      │ Alice              │ Bob                         │
│ S2      │ Bob                │ Charlie                     │
│ S3      │ Charlie            │ David                       │
│ S4      │ David              │ Alice                       │
└─────────────────────────────────────────────────────────────┘

AVANTAGES:
├── Charge distribuée
├── Connaissance partagée du code
├── Pas de personne indispensable
└── Mentorat naturel

RÈGLES:
├── Le principal revoit en premier
├── Le backup intervient si > 4h
├── Pairs pour PR complexes
└── Expert domaine consultable

Qualité du Feedback

Donner un Bon Feedback

TYPES DE COMMENTAIRES:
═══════════════════════

OBLIGATOIRE (blocker):
┌─────────────────────────────────────────────────────────────┐
│ 🚨 [BLOCKER] Injection SQL possible ici.                   │
│ La requête concatène l'input utilisateur directement.      │
│ Utiliser des paramètres préparés.                          │
│                                                             │
│ Avant: query = "SELECT * FROM users WHERE id=" + userId    │
│ Après: query = "SELECT * FROM users WHERE id=?", [userId]  │
└─────────────────────────────────────────────────────────────┘

SUGGESTION (non-blocker):
┌─────────────────────────────────────────────────────────────┐
│ 💡 [SUGGESTION] Considère extraire cette logique dans     │
│ une fonction séparée pour améliorer la testabilité.        │
│ Pas bloquant pour cette PR.                                │
└─────────────────────────────────────────────────────────────┘

QUESTION (clarification):
┌─────────────────────────────────────────────────────────────┐
│ ❓ [QUESTION] Pourquoi ce timeout de 30 secondes?          │
│ Est-ce basé sur des métriques ou une valeur par défaut?    │
└─────────────────────────────────────────────────────────────┘

COMPLIMENT (encouragement):
┌─────────────────────────────────────────────────────────────┐
│ 👍 Super refactoring de ce module! Beaucoup plus lisible.  │
└─────────────────────────────────────────────────────────────┘

Ton Bienveillant

COMMUNICATION RESPECTUEUSE:
════════════════════════════

À ÉVITER:
├── ❌ "C'est mal fait"
├── ❌ "Pourquoi tu as fait ça?"
├── ❌ "Ça ne marchera jamais"
├── ❌ "Tu devrais savoir que..."
└── ❌ "C'est évident que..."

À PRÉFÉRER:
├── ✅ "Que penses-tu de cette approche...?"
├── ✅ "Je suggère de considérer..."
├── ✅ "Dans mon expérience, ceci pourrait..."
├── ✅ "Pourrais-tu m'expliquer la raison de...?"
└── ✅ "J'ai remarqué que... qu'en penses-tu?"

RÈGLE D'OR:
┌─────────────────────────────────────────────────────────────┐
│ Critique le code, pas la personne.                         │
│ Assume les meilleures intentions.                          │
│ Propose des solutions, pas juste des problèmes.            │
└─────────────────────────────────────────────────────────────┘

Automatisation

Ce Qu'il Faut Automatiser

AUTOMATISATION CI/CD:
═════════════════════

PRÉ-REVUE (bloque si échec):
┌─────────────────────────────────────────────────────────────┐
│ ✅ Linting (ESLint, Pylint, etc.)                          │
│ ✅ Formatage (Prettier, Black)                             │
│ ✅ Tests unitaires                                          │
│ ✅ Analyse statique (SonarQube, CodeClimate)               │
│ ✅ Vérification des types                                   │
│ ✅ Vulnérabilités de dépendances                           │
│ ✅ Couverture de code minimum                              │
└─────────────────────────────────────────────────────────────┘

AIDE À LA REVUE:
┌─────────────────────────────────────────────────────────────┐
│ 📊 Taille de la PR (lignes changées)                       │
│ 📊 Fichiers modifiés (par domaine)                         │
│ 📊 Changement de couverture                                │
│ 📊 Complexité cyclomatique                                  │
│ 📊 Assignation automatique reviewer                        │
└─────────────────────────────────────────────────────────────┘

RÉSULTAT:
Les reviewers se concentrent sur la logique, pas le style.

Configuration Type

WORKFLOW PR OPTIMISÉ:
═════════════════════

PR CRÉÉE
    │
    ▼
┌───────────────────┐
│ CI AUTOMATIQUE    │
├───────────────────┤
│ • Build           │
│ • Lint            │
│ • Tests           │
│ • Coverage        │
└─────────┬─────────┘
          │
    ┌─────▼─────┐
    │ Échec?    │──Non──→ Notification reviewer
    └─────┬─────┘              │
          │Oui                 ▼
          ▼             ┌─────────────────┐
    Notification        │ REVUE HUMAINE   │
    Auteur             │ Focus: Logique   │
    "Corriger CI"      │ Design, Sécurité │
                       └─────────┬────────┘
                                 │
                                 ▼
                           APPROBATION
                                 │
                                 ▼
                             MERGE

Culture de Revue

Établir des Standards

DOCUMENT DE STANDARDS ÉQUIPE:
══════════════════════════════

1. OBJECTIFS DE LA REVUE:
   ├── Améliorer la qualité du code
   ├── Partager les connaissances
   ├── Maintenir la cohérence
   └── Prévenir les bugs

2. ATTENTES:
   ├── Auteur: PR prête (tests OK, CI vert)
   ├── Reviewer: Feedback dans les 4h
   ├── Tous: Communication respectueuse
   └── Tous: Apprendre mutuellement

3. ESCALADE:
   ├── Désaccord technique → Discussion vocale
   ├── Blocage > 24h → Scrum Master
   └── Récurrence → Rétrospective

4. MÉTRIQUES ÉQUIPE:
   ├── Temps moyen de revue: < 24h
   ├── Rounds moyens: < 2
   └── Satisfaction: > 4/5

Amélioration Continue

RÉTROSPECTIVE REVUE DE CODE:
═════════════════════════════

QUESTIONS MENSUELLES:
┌─────────────────────────────────────────────────────────────┐
│                                                             │
│ 1. Nos revues sont-elles utiles?                           │
│    ├── Bugs trouvés en revue vs production                 │
│    └── Feedback actionnable reçu                           │
│                                                             │
│ 2. Nos revues sont-elles rapides?                          │
│    ├── Temps moyen première réponse                        │
│    └── Temps total jusqu'à merge                           │
│                                                             │
│ 3. Nos revues sont-elles respectueuses?                    │
│    ├── Sondage anonyme équipe                              │
│    └── Incidents de communication                          │
│                                                             │
│ 4. Quoi améliorer?                                         │
│    ├── Automatiser plus?                                   │
│    ├── Former les nouveaux?                                │
│    └── Ajuster les SLA?                                    │
│                                                             │
└─────────────────────────────────────────────────────────────┘

Liens Connexes

Retour aux Guides Pratiques