9 min lecture • Guide 35 of 877
Configurer des Workflows de Revue de Code Efficaces
Les revues de code sont critiques pour maintenir la qualité, partager les connaissances et détecter les bugs avant la production. Mais des processus de revue mal conçus peuvent devenir des goulots d'étranglement qui frustrent les développeurs et ralentissent les livraisons. Les intégrations et fonctionnalités de workflow de GitScrum aident à établir des pratiques de revue qui sont approfondies mais efficaces.
Le Défi de la Revue de Code
Problèmes de revue courants:
| Problème | Impact |
|---|---|
| Revues trop longues | PRs s'accumulent, contexte perdu |
| Standards inconsistants | Qualité varie par réviseur |
| Attentes floues | Nitpicking vs. feedback important |
| Goulots réviseurs | Une personne bloque tous les PRs |
| Pas de responsabilité | Revues ignorées ou retardées |
Configuration Intégration GitScrum
Connexion Fournisseurs Git
Intégration Fournisseur Git:
PLATEFORMES SUPPORTÉES:
├── GitHub (Cloud & Enterprise)
├── GitLab (Cloud & Self-hosted)
└── Bitbucket (Cloud & Server)
ÉTAPES DE CONNEXION:
1. Settings → Integrations → Git Providers
2. Sélectionner fournisseur
3. Autoriser connexion OAuth
4. Choisir dépôts à connecter
5. Configurer paramètres synchronisation
OPTIONS SYNC:
┌─────────────────────────────────────────────────────────────┐
│ Configuration Intégration Git │
├─────────────────────────────────────────────────────────────┤
│ Dépôt: acme/frontend │
│ │
│ Paramètres Sync: │
│ ☑ Lier branches aux tâches (pattern: TASK-###) │
│ ☑ Lier PRs aux tâches │
│ ☑ Mettre à jour statut tâche sur événements PR │
│ ☑ Afficher statut PR dans détails tâche │
│ ☑ Importer commentaires PR comme commentaires tâche │
│ │
│ Mapping Statuts: │
│ PR Ouvert → Déplacer tâche vers: [En Revue ▼] │
│ PR Approuvé → Déplacer tâche vers: [Approuvé ▼] │
│ PR Fusionné → Déplacer tâche vers: [Fait ▼] │
│ PR Fermé → Déplacer tâche vers: [Pas de changement ▼]│
└─────────────────────────────────────────────────────────────┘
Liaison Automatique Tâches
Convention Nommage Branches:
PATTERN: [type]/TASK-[id]-[description]
Exemples:
├── feature/TASK-456-user-search
├── fix/TASK-789-login-bug
├── refactor/TASK-101-cleanup-auth
└── chore/TASK-202-update-deps
Flux Auto-Détection:
┌─────────────────────────────────────────────────────────────┐
│ 1. Développeur crée branche: │
│ git checkout -b feature/TASK-456-user-search │
│ │
│ 2. GitScrum détecte pattern "TASK-456" │
│ │
│ 3. Tâche TASK-456 auto-mise à jour: │
│ ├── Statut: → En Cours │
│ ├── Branche: feature/TASK-456-user-search │
│ └── Activité: "Branche créée par @alice" │
│ │
│ 4. Quand PR ouvert: │
│ ├── PR lié à tâche │
│ ├── Statut: → En Revue │
│ └── Activité: "PR #123 ouvert" │
│ │
│ 5. Quand PR fusionné: │
│ ├── Statut: → Fait │
│ └── Activité: "PR #123 fusionné vers main" │
└─────────────────────────────────────────────────────────────┘
Assignation Réviseurs
Règles Assignation Automatisée
Configuration Assignation Réviseurs:
STRATÉGIES ASSIGNATION:
┌─────────────────────────────────────────────────────────────┐
│ Règles Assignation Réviseurs │
├─────────────────────────────────────────────────────────────┤
│ │
│ Stratégie: [Round Robin ▼] │
│ │
│ Options: │
│ ├── Round Robin: Rotation entre membres équipe │
│ ├── Load Balanced: Assigner à personne avec moins revues │
│ ├── Code Ownership: Basé sur chemins fichiers modifiés │
│ ├── Aléatoire: Sélection random du pool │
│ └── Manuel: Auteur sélectionne, avec suggestions │
│ │
│ Pool Réviseurs: [Équipe Frontend ▼] │
│ ├── @alice (senior) │
│ ├── @bob (senior) │
│ ├── @carol (mid) │
│ └── @david (mid) │
│ │
│ Réviseurs Requis: [2] │
│ │
│ Règles: │
│ ☑ Au moins 1 réviseur senior │
│ ☑ Ne peut réviser ses propres PRs │
│ ☑ Exclure en congé (sync depuis calendrier) │
│ □ Requérir réviseur spécifique pour [security/*] │
└─────────────────────────────────────────────────────────────┘
Mapping Ownership Code
Assignation style CODEOWNERS:
Règles Chemin Fichier:
┌─────────────────────────────────────────────────────────────┐
│ Configuration Ownership Code │
├─────────────────────────────────────────────────────────────┤
│ │
│ Pattern Chemin Owners Requis │
│ ───────────────────────────────────────────────────────────│
│ /src/api/* @api-team 1 │
│ /src/components/ui/* @ui-team 1 │
│ /src/auth/* @security-team 2 │
│ /src/payments/* @payments-lead 1 + @security │
│ /database/* @dba-team 1 │
│ *.sql @dba-team 1 │
│ /tests/* @qa-lead Optionnel │
│ * @default-reviewers 1 │
│ │
│ Priorité: Première correspondance gagne (haut vers bas) │
└─────────────────────────────────────────────────────────────┘
Équilibrage Charge Revues
Assignation Équilibrée par Charge:
CHARGE REVUE ACTUELLE:
┌─────────────────────────────────────────────────────────────┐
│ CHARGE TRAVAIL RÉVISEURS [Cette Semaine] │
├─────────────────────────────────────────────────────────────┤
│ │
│ Revues Actives: │
│ Alice: [██░░░░░░] 2 PRs (capacité: 4) ← Proch assign │
│ Bob: [████░░░░] 4 PRs (capacité: 4) Plein │
│ Carol: [███░░░░░] 3 PRs (capacité: 4) │
│ David: [██░░░░░░] 2 PRs (capacité: 4) ← Proch assign │
│ │
│ Stats Revue Cette Semaine: │
│ ├── Alice: 8 complétées, moy 4h réponse │
│ ├── Bob: 6 complétées, moy 6h réponse │
│ ├── Carol: 7 complétées, moy 3h réponse │
│ └── David: 5 complétées, moy 8h réponse │
└─────────────────────────────────────────────────────────────┘
SLAs Revue et Suivi
Attentes Basées sur Temps
Configuration SLA Revue:
┌─────────────────────────────────────────────────────────────┐
│ SLAs Revue Code │
├─────────────────────────────────────────────────────────────┤
│ │
│ SLA Première Réponse: │
│ ├── P0/Critique: 2 heures │
│ ├── P1/Haute: 4 heures │
│ ├── P2/Normal: 8 heures (1 jour ouvré) │
│ └── P3/Basse: 24 heures │
│ │
│ SLA Complétion Revue: │
│ ├── Petit PR (<100 lignes): 4h après première réponse │
│ ├── PR Moyen (100-500 lignes): 8 heures │
│ └── Grand PR (>500 lignes): 24 heures │
│ │
│ Règles Escalade: │
│ ├── 50% du SLA: Rappel au réviseur │
│ ├── 100% du SLA: Notifier team lead │
│ ├── 150% du SLA: Escalader à eng manager │
│ └── 200% du SLA: Permettre merge sans revue complète │
└─────────────────────────────────────────────────────────────┘
Dashboard Statut Revue
Dashboard Pipeline Revue:
┌─────────────────────────────────────────────────────────────┐
│ PIPELINE REVUE CODE [Derniers 7 Jours ▼]│
├─────────────────────────────────────────────────────────────┤
│ │
│ Statut Actuel: │
│ ├── En Attente Revue: 8 PRs │
│ ├── En Revue: 5 PRs │
│ ├── Changements Demandés: 3 PRs │
│ └── Approuvés (merge en attente): 2 PRs │
│ │
│ Performance SLA: │
│ │ Première Réponse │
│ │ À Temps: ████████████████████ 85% │
│ │ Retard: ████ 15% │
│ │ │
│ │ Complétion Revue │
│ │ À Temps: ██████████████████ 78% │
│ │ Retard: ██████ 22% │
│ │
│ PRs Risque SLA: │
│ ├── 🔴 PR #456: 6h retard (assigné: @bob) │
│ ├── 🟡 PR #461: 2h restantes (assigné: @carol) │
│ └── 🟡 PR #463: 3h restantes (assigné: @alice) │
└─────────────────────────────────────────────────────────────┘
Checklists Revue
Critères Revue Standardisés
Template Checklist Revue Code:
┌─────────────────────────────────────────────────────────────┐
│ CHECKLIST REVUE PR │
├─────────────────────────────────────────────────────────────┤
│ │
│ FONCTIONNALITÉ │
│ □ Code fait ce que la description tâche dit │
│ □ Cas edge sont gérés │
│ □ Gestion erreurs est appropriée │
│ □ Pas de bugs évidents │
│ │
│ QUALITÉ CODE │
│ □ Code est lisible et auto-documenté │
│ □ Fonctions/méthodes ont taille appropriée │
│ □ Pas de duplication code │
│ □ Suit conventions et patterns du projet │
│ │
│ TESTING │
│ □ Tests unitaires couvrent nouvelle fonctionnalité │
│ □ Tests sont significatifs (pas juste couverture) │
│ □ Cas edge sont testés │
│ □ Tests passent local et en CI │
│ │
│ SÉCURITÉ │
│ □ Pas de données sensibles exposées │
│ □ Validation input en place │
│ □ Authentification/autorisation correcte │
│ □ Pas de vulnérabilités SQL injection ou XSS │
│ │
│ PERFORMANCE │
│ □ Pas de problèmes performance évidents │
│ □ Requêtes DB sont efficaces (pas N+1) │
│ □ Caching approprié considéré │
└─────────────────────────────────────────────────────────────┘
Qualité Feedback
Catégories Commentaires
Types Feedback Structuré:
PRÉFIXES COMMENTAIRE:
┌─────────────────────────────────────────────────────────────┐
│ Préfixe Signification Bloquant? │
├─────────────────────────────────────────────────────────────┤
│ [BLOCKER] Doit corriger avant merge Oui │
│ [ISSUE] Devrait corriger, important Oui (souvent) │
│ [SUGGEST] Considérer changer Non │
│ [NIT] Mineur/préférence style Non │
│ [QUESTION] Besoin clarification Dépend │
│ [PRAISE] Bon travail, bon code Non │
│ [FYI] Partage information Non │
└─────────────────────────────────────────────────────────────┘
Exemples:
[BLOCKER] Cette requête SQL est vulnérable à l'injection.
Veuillez utiliser des requêtes paramétrées.
[ISSUE] Cette fonction fait 200 lignes. Considérez diviser
en fonctions plus petites pour testabilité.
[SUGGEST] Vous pourriez simplifier ceci avec un reduce()
[NIT] Je préférerais `isActive` plutôt que `active` pour noms boolean.
[PRAISE] Implémentation très propre de la couche cache!
Workflows Approbation
Approbations Multi-Étapes
Exigences Approbation:
PR STANDARD:
┌─────────────────────────────────────────────────────────────┐
│ Exigences pour Merge: │
│ ├── 1+ approbation de l'équipe │
│ ├── Tous blockers résolus │
│ ├── Checks CI passent │
│ └── Pas de threads non résolus │
└─────────────────────────────────────────────────────────────┘
ZONES SENSIBLES:
┌─────────────────────────────────────────────────────────────┐
│ Chemin: /src/auth/*, /src/payments/* │
│ Exigences: │
│ ├── 2+ approbations │
│ ├── 1 doit être de l'équipe sécurité │
│ ├── Toutes checklists complètes │
│ └── CI étendu (scans sécurité) │
└─────────────────────────────────────────────────────────────┘
Meilleures Pratiques
Pour Auteurs
- Garder PRs petits — <300 lignes idéal, <500 max
- Écrire bonnes descriptions — Contexte, quoi, pourquoi, comment
- Auto-réviser d'abord — Attraper problèmes évidents
- Répondre promptement — Adresser feedback rapidement
- Ne pas prendre personnellement — Revues améliorent code, ne jugent pas
Pour Réviseurs
- Être ponctuel — Respecter le SLA
- Être spécifique — Pointer lignes exactes, suggérer fixes
- Être gentil — Critiquer code, pas personnes
- Prioriser feedback — Blockers > Issues > Nits
- Apprendre en révisant — C'est partage connaissances
Pour Équipes
- Définir standards clairs — Documenter à quoi ressemble le bon
- Rotation réviseurs — Répandre connaissances
- Tracker métriques — Améliorer au fil du temps
- Célébrer bonnes revues — Renforcer qualité
- Rétrospectives régulières — Affiner le processus