7 min lecture • Guide 679 of 877
Améliorer la Qualité des Revues de Code
Les revues de code de haute qualité détectent les bugs, partagent les connaissances et améliorent la qualité du code dans toute l'équipe. GitScrum aide à suivre le statut des revues, identifier les goulots d'étranglement et maintenir la visibilité sur le processus de revue comme partie intégrante du workflow de développement.
Framework de Qualité de Revue
Quoi Réviser
DOMAINES DE FOCUS REVUE DE CODE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ HAUTE PRIORITÉ (Toujours réviser): │
│ ✓ Correction de la logique │
│ ✓ Vulnérabilités de sécurité │
│ ✓ Gestion des erreurs │
│ ✓ Cas limites │
│ ✓ Changements cassants │
│ │
│ MOYENNE PRIORITÉ (Généralement réviser): │
│ ✓ Implications de performance │
│ ✓ Couverture de tests │
│ ✓ Design d'API │
│ ✓ Maintenabilité du code │
│ ✓ Exactitude de la documentation │
│ │
│ BASSE PRIORITÉ (Automatiser si possible): │
│ ○ Formatage et style │
│ ○ Ordre des imports │
│ ○ Conventions de nommage │
│ ○ Règles de linting simples │
│ │
│ AUTOMATISER: Utilisez linters, formatters, type checkers │
│ Les reviewers humains se concentrent sur ce que les │
│ machines ne peuvent pas faire │
└─────────────────────────────────────────────────────────────┘
Checklist de Revue
CHECKLIST DU REVIEWER:
┌─────────────────────────────────────────────────────────────┐
│ │
│ AVANT DE RÉVISER: │
│ ☐ Lire la description de PR et la tâche liée │
│ ☐ Comprendre le contexte et l'objectif │
│ ☐ Vérifier que CI passe │
│ ☐ Estimer le temps de revue │
│ │
│ PENDANT LA REVUE: │
│ ☐ Le code fait-il ce qu'il devrait? │
│ ☐ Les cas limites sont-ils gérés? │
│ ☐ Les erreurs sont-elles correctement gérées? │
│ ☐ Y a-t-il des problèmes de sécurité? │
│ ☐ Les tests sont-ils suffisants? │
│ ☐ Le code est-il lisible et maintenable? │
│ ☐ La documentation est-elle à jour? │
│ │
│ FEEDBACK: │
│ ☐ Distinguer bloquant vs suggestion │
│ ☐ Expliquer le "pourquoi" │
│ ☐ Proposer des solutions │
│ ☐ Reconnaître ce qui est bien fait │
│ │
└─────────────────────────────────────────────────────────────┘
Améliorer la Profondeur
Niveaux de Revue
PROFONDEUR DE REVUE PAR TYPE:
═════════════════════════════
REVUE LÉGÈRE (< 100 lignes, faible risque):
┌─────────────────────────────────────────────────────────────┐
│ • Vérification rapide de la logique │
│ • Pas de problèmes évidents │
│ • Tests présents et passent │
│ • Temps: 10-15 minutes │
└─────────────────────────────────────────────────────────────┘
REVUE STANDARD (100-400 lignes):
┌─────────────────────────────────────────────────────────────┐
│ • Analyse de la logique détaillée │
│ • Vérification des cas limites │
│ • Qualité des tests │
│ • Design et architecture │
│ • Temps: 30-60 minutes │
└─────────────────────────────────────────────────────────────┘
REVUE APPROFONDIE (code critique, changements majeurs):
┌─────────────────────────────────────────────────────────────┐
│ • Exécution mentale du code │
│ • Analyse de sécurité │
│ • Implications de performance │
│ • Impact sur l'architecture │
│ • Discussion avec l'auteur si besoin │
│ • Temps: 1-2 heures+ │
└─────────────────────────────────────────────────────────────┘
Questions à Poser
QUESTIONS POUR UNE REVUE APPROFONDIE:
═════════════════════════════════════
CORRECTION:
├── Ce code gère-t-il correctement les entrées nulles?
├── Que se passe-t-il si la requête échoue?
├── Les races conditions sont-elles possibles?
└── Le comportement concurrent est-il thread-safe?
DESIGN:
├── Cette abstraction est-elle au bon niveau?
├── Serait-ce plus clair avec une autre approche?
├── Ce code est-il facilement testable?
└── Respecte-t-il les patterns établis?
MAINTENABILITÉ:
├── Un nouveau développeur comprendrait-il ce code?
├── Les noms sont-ils clairs et descriptifs?
├── Y a-t-il de la duplication à extraire?
└── Les commentaires sont-ils utiles?
PERFORMANCE:
├── Y a-t-il des N+1 queries?
├── Les boucles sont-elles efficaces?
├── La mémoire est-elle gérée correctement?
└── Faut-il de la mise en cache?
Donner un Bon Feedback
Structure du Feedback
ANATOMIE D'UN BON COMMENTAIRE:
═══════════════════════════════
MODÈLE:
[TYPE] Observation + Explication + Suggestion
EXEMPLE - BLOQUANT:
┌─────────────────────────────────────────────────────────────┐
│ 🚨 [BLOQUANT] │
│ │
│ Cette requête est vulnérable à l'injection SQL car │
│ elle concatène directement l'input utilisateur. │
│ │
│ Suggestion: Utiliser des paramètres préparés: │
│ ``` │
│ cursor.execute("SELECT * FROM users WHERE id=?", [userId]) │
│ ``` │
│ │
│ Référence: OWASP SQL Injection Prevention │
└─────────────────────────────────────────────────────────────┘
EXEMPLE - SUGGESTION:
┌─────────────────────────────────────────────────────────────┐
│ 💡 [SUGGESTION] Non-bloquant │
│ │
│ Considère extraire cette logique dans une fonction │
│ `validateUserInput()` pour améliorer la testabilité │
│ et la réutilisation. │
│ │
│ Ça rendrait aussi le test plus facile à écrire. │
└─────────────────────────────────────────────────────────────┘
EXEMPLE - QUESTION:
┌─────────────────────────────────────────────────────────────┐
│ ❓ [QUESTION] │
│ │
│ Je vois que le timeout est de 30 secondes. Est-ce basé │
│ sur des mesures de performance ou c'est une valeur │
│ par défaut? Je me demande si ça pourrait être trop long │
│ pour l'UX. │
└─────────────────────────────────────────────────────────────┘
Équilibrer les Retours
RATIO FEEDBACK:
════════════════
RÈGLE DU 3:1:
Pour chaque critique, essayer de trouver quelque chose de positif
BON EXEMPLE:
┌─────────────────────────────────────────────────────────────┐
│ ✅ Super refactoring du module auth! Beaucoup plus lisible │
│ ✅ Bonne couverture de tests pour les cas limites │
│ 💡 Suggestion: extraire la validation dans une fonction │
│ ✅ Le handling d'erreurs est très propre │
└─────────────────────────────────────────────────────────────┘
ÉVITER:
├── ❌ Que des critiques sans positif
├── ❌ Commentaires vagues ("ça ne me plaît pas")
├── ❌ Critiques sans suggestions
├── ❌ Ton condescendant ou sarcastique
└── ❌ Nitpicks sur le style (automatiser!)
Processus d'Amélioration
Métriques de Qualité
MESURES DE QUALITÉ DE REVUE:
════════════════════════════
MÉTRIQUES QUANTITATIVES:
┌─────────────────────────────────────────────────────────────┐
│ Métrique │ Objectif │ Actuel │ Tendance │
├─────────────────────────────────────────────────────────────┤
│ Bugs trouvés en revue │ > 5/mois │ 7 │ ↑ │
│ Bugs échappés à production │ < 3/mois │ 2 │ ↓ │
│ Temps première réponse │ < 4h │ 3.2h │ ✓ │
│ Rounds moyens │ < 2 │ 1.8 │ ✓ │
│ Commentaires par PR │ 3-8 │ 5 │ → │
└─────────────────────────────────────────────────────────────┘
MÉTRIQUES QUALITATIVES (sondage équipe):
├── "Les revues m'aident à apprendre" (4.2/5)
├── "Les retours sont constructifs" (4.5/5)
├── "Les revues sont rapides" (3.8/5)
└── "Je comprends les attentes" (4.1/5)
Formation et Standards
AMÉLIORATION CONTINUE:
═══════════════════════
ONBOARDING NOUVEAUX REVIEWERS:
├── Shadow: Observer des revues seniors
├── Pair: Réviser ensemble
├── Solo: Revues validées par senior
└── Autonome: Revue indépendante
SESSIONS D'ÉQUIPE:
├── Revue de code exemplaire (mensuel)
├── Analyse de bugs échappés
├── Mise à jour des guidelines
└── Partage de nouvelles techniques
DOCUMENTATION:
├── Guide de revue de l'équipe
├── Exemples de bons commentaires
├── Checklist par type de changement
└── FAQ des questions courantes
GitScrum pour les Revues
Suivi et Visibilité
FONCTIONNALITÉS GITSCRUM:
═════════════════════════
SUIVI DE STATUT:
┌─────────────────────────────────────────────────────────────┐
│ Tâche T-123: Authentification OAuth │
├─────────────────────────────────────────────────────────────┤
│ Statut: En Revue │
│ PR: github.com/project/pr/456 │
│ Assigné: Alice │
│ Reviewer: Bob │
│ En revue depuis: 4h │
│ SLA: ⚠️ Approche limite (4h) │
└─────────────────────────────────────────────────────────────┘
MÉTRIQUES ÉQUIPE:
├── Temps moyen en revue: 6.2h
├── PR en attente: 3
├── Reviewer le plus sollicité: Alice (8 PR/sem)
└── Goulot identifié: Revue backend