6 min lecture • Guide 634 of 877
Meilleures Pratiques de Revue de Code
Les revues de code efficaces équilibrent rigueur et rapidité, détectant les problèmes importants tout en évitant les goulots d'étranglement qui ralentissent la livraison. L'intégration de GitScrum avec les outils de revue de code aide les équipes à suivre le statut des revues, identifier les goulots et s'assurer que les revues se font rapidement sans bloquer les développeurs.
Conception du Processus de Revue
SLA de Revue
NIVEAUX DE SERVICE REVUE DE CODE :
┌─────────────────────────────────────────────────────────────┐
│ MÉTRIQUE │ CIBLE │ ACTION SI MANQUÉ │
├─────────────────────────┼─────────────┼─────────────────────┤
│ Première réponse │ < 4 heures │ Rappel dans Slack │
│ Revue complète │ < 24 heures │ Escalade au lead │
│ Merge PR après approbat.│ < 2 heures │ Auteur notifié │
│ Délai de révision │ < 4 heures │ Priorité augmentée │
└─────────────────────────────────────────────────────────────┘
Suivre dans GitScrum :
• Dashboard montre temps moyen de revue
• Alertes pour PR obsolètes
• Métriques d'équipe pour vélocité des revues
Directives sur la Taille des PR
TAILLE OPTIMALE DE PR :
┌─────────────────────────────────────────────────────────────┐
│ │
│ LIGNES CODE │ TEMPS REVUE │ DÉTECTION DÉFAUTS │
├─────────────┼─────────────┼─────────────────────────────────┤
│ < 200 │ 15-30 min │ Haute - revue approfondie │
│ 200-400 │ 30-60 min │ Bonne - revue efficace │
│ 400-800 │ 1-2 heures │ Moyenne - fatigue du revieweur │
│ > 800 │ 2+ heures │ Basse - revue superficielle │
└───────────────────────────────────────────────────────────────┘
STRATÉGIES POUR DES PR PLUS PETITES :
• Livrer le refactoring séparément des fonctionnalités
• Diviser grandes fonctionnalités en changements incrémentaux
• Utiliser feature flags pour implémentations partielles
• Séparer ajouts de tests des changements de code
Qualité de Revue
Quoi Rechercher
CHECKLIST DE REVUE DE CODE :
┌─────────────────────────────────────────────────────────────┐
│ │
│ EXACTITUDE : │
│ □ Fait-il ce qu'il est censé faire ? │
│ □ Cas limites gérés ? │
│ □ Conditions d'erreur couvertes ? │
│ │
│ CONCEPTION : │
│ □ L'approche est-elle appropriée ? │
│ □ Correspond-elle à l'architecture ? │
│ □ Est-ce maintenable ? │
│ │
│ LISIBILITÉ : │
│ □ Nommage clair ? │
│ □ Commentaires appropriés ? │
│ □ Complexité raisonnable ? │
│ │
│ TESTS : │
│ □ Tests inclus ? │
│ □ Couverture de test adéquate ? │
│ □ Cas limites testés ? │
│ │
│ SÉCURITÉ : │
│ □ Pas de données sensibles exposées ? │
│ □ Validation d'entrée présente ? │
│ □ Authentification/autorisation correcte ? │
└─────────────────────────────────────────────────────────────┘
Feedback Constructif
COMMENTAIRES DE REVUE EFFICACES :
┌─────────────────────────────────────────────────────────────┐
│ │
│ AU LIEU DE : ESSAYEZ : │
├───────────────────────────────┼─────────────────────────────┤
│ "C'est faux" │ "Cela pourrait causer X. │
│ │ Considérez Y à la place?" │
├───────────────────────────────┼─────────────────────────────┤
│ "Mauvais nommage" │ "Que diriez-vous de │
│ │ `userCount` pour clarté?" │
├───────────────────────────────┼─────────────────────────────┤
│ "Pourquoi avez-vous fait ça?" │ "Je suis curieux du │
│ │ raisonnement ici - pouvez-│
│ │ vous expliquer ?" │
└─────────────────────────────────────────────────────────────┘
PRÉFIXES DE COMMENTAIRES :
[nit] - Préférence de style mineure, optionnel
[suggestion] - Considérez cette approche
[question] - Besoin de clarification
[bloquant] - Doit être corrigé avant merge
Workflow de Revue
Intégration GitScrum
CYCLE DE VIE PR → TÂCHE :
┌─────────────────────────────────────────────────────────────┐
│ │
│ MISES À JOUR AUTOMATIQUES DE STATUT : │
│ │
│ PR Créée → Tâche passe à "En Revue" │
│ Revue Faite → Tâche montre badge "Approuvée" │
│ Modifs Req → Tâche montre "Modifications Demandées" │
│ PR Mergée → Tâche passe à "Fait" │
│ │
│ VUE TÂCHE GITSCRUM : │
│ ┌────────────────────────────────────────────────────────┐ │
│ │ Tâche #234 : Authentification Utilisateur │ │
│ │ Statut : En Revue │ │
│ │ │ │
│ │ PR Liée : #456 - Implémenter flux de connexion │ │
│ │ ✓ CI Passé | 👀 2 revieweurs | 💬 5 commentaires │ │
│ │ Dernière activité : il y a 2 heures │ │
│ └────────────────────────────────────────────────────────┘ │
└─────────────────────────────────────────────────────────────┘
Attribution des Revieweurs
SÉLECTION DES REVIEWEURS :
┌─────────────────────────────────────────────────────────────┐
│ │
│ ATTRIBUTION AUTOMATIQUE : │
│ • Rotation parmi l'équipe │
│ • Code owners pour chemins spécifiques │
│ • Basée sur tags d'expertise │
│ │
│ CONSIDÉRATIONS : │
│ • Équilibrer charge de revue dans l'équipe │
│ • Inclure expert du domaine pour changements complexes │
│ • Juniors reviewent pour apprendre │
│ • Senior review pour chemins critiques │
│ │
│ SUIVI GITSCRUM : │
│ • Charge de revue par membre │
│ • Temps moyen de revue par revieweur │
│ • Métriques de qualité de revue │
└─────────────────────────────────────────────────────────────┘
Mesurer l'Efficacité des Revues
Métriques de Revue
MÉTRIQUES CLÉS DE REVUE :
┌─────────────────────────────────────────────────────────────┐
│ │
│ MÉTRIQUES DE PROCESSUS : │
│ • Temps jusqu'à première revue : 3.2h en moyenne │
│ • Temps jusqu'au merge : 18h en moyenne │
│ • Cycles de révision : 1.3 en moyenne │
│ │
│ MÉTRIQUES DE QUALITÉ : │
│ • Problèmes trouvés en revue : 2.1 par PR en moyenne │
│ • Bugs post-merge : 0.3 par PR en moyenne │
│ • Taux d'échappement : 5% │
│ │
│ SANTÉ D'ÉQUIPE : │
│ • Participation aux revues : 85% de l'équipe │
│ • Distribution de charge : Uniforme (±15%) │
│ • Ton des commentaires : Constructif │
└─────────────────────────────────────────────────────────────┘