7 min lecture • Guide 111 of 877
Maintenir Standards Code Review Cohérents
Les standards code review éliminent débats subjectifs en définissant ce que "suffisamment bon" signifie pour votre équipe. Les intégrations GitHub, GitLab, et Bitbucket de GitScrum affichent activité pull request aux côtés du suivi tâches, tandis que documentation NoteVault et checklists révision aident équipes à maintenir attentes cohérentes, réduire temps révision, et transformer code review en opportunité apprentissage plutôt que goulot.
Établir Standards
Framework Critères Review
DIMENSIONS CODE REVIEW:
┌─────────────────────────────────────────────────────────────┐
│ QUOI RÉVISER │
├─────────────────────────────────────────────────────────────┤
│ │
│ TIER 1: DOIT PASSER (Bloquant) │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ☐ Fonctionne correctement (implémente exigences) ││
│ │ ☐ Pas de bugs évidents ou cas limites ││
│ │ ☐ Tests passent (unit, intégration) ││
│ │ ☐ Pas de vulnérabilités sécurité introduites ││
│ │ ☐ Pas de changements cassants sans chemin migration ││
│ │ ☐ Pas de données sensibles exposées (clés, mots passe) ││
│ │ ││
│ │ Statut: PR ne peut pas merger jusqu'à tout vérifié ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ TIER 2: DEVRAIT PASSER (Haute Priorité) │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ☐ Code est lisible et compréhensible ││
│ │ ☐ Suit conventions nommage équipe ││
│ │ ☐ Gestion erreurs est appropriée ││
│ │ ☐ Performance est acceptable ││
│ │ ☐ A couverture tests suffisante ││
│ │ ☐ Documentation mise à jour si nécessaire ││
│ │ ││
│ │ Statut: Traiter avant merge, ou créer tâche follow-up ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ TIER 3: BON À AVOIR (Suggestions) │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ☐ Pourrait être plus élégant/concis ││
│ │ ☐ Préférences style mineures ││
│ │ ☐ Approches alternatives à considérer ││
│ │ ☐ Opportunités refactoring pour plus tard ││
│ │ ││
│ │ Statut: Non-bloquant, auteur décide si traiter ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ DOCUMENTER DANS NOTEVAULT: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Créer document "Standards Code Review" pour équipe ││
│ │ Inclure exemples pour chaque tier ││
│ │ Référencer dans template PR ││
│ │ Réviser trimestriellement pour mises à jour ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Convention Commentaires
TYPES COMMENTAIRES REVIEW:
┌─────────────────────────────────────────────────────────────┐
│ PRÉFIXES COMMENTAIRES CLAIRS │
├─────────────────────────────────────────────────────────────┤
│ │
│ BLOQUANT: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ [BLOQUANT] Ceci causera null pointer en production ││
│ │ ││
│ │ Signification: PR ne peut merger jusqu'à traité ││
│ │ Responsabilité réviseur: Expliquer pourquoi bloquant ││
│ │ Réponse auteur: Doit corriger ou discuter ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ QUESTION: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ [QUESTION] Pourquoi mettons-nous en cache 24 heures? ││
│ │ ││
│ │ Signification: Besoin comprendre avant approuver ││
│ │ Responsabilité réviseur: Curiosité genuína ││
│ │ Réponse auteur: Expliquer raisonnement ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ SUGGESTION: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ [SUGGESTION] Considérer Optional ici à la place ││
│ │ ││
│ │ Signification: Idée amélioration non-bloquante ││
│ │ Responsabilité réviseur: Proposer alternative ││
│ │ Réponse auteur: Prendre ou laisser, pas discussion req. ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ NIT: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ [NIT] Typo dans nom variable: "recieve" → "receive" ││
│ │ ││
│ │ Signification: Trivial, corriger si facile ││
│ │ Responsabilité réviseur: Garder ces minimums ││
│ │ Réponse auteur: Fix rapide ou ignorer ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ÉLOGE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ [BIEN] Solution propre, j'ai appris quelque chose ││
│ │ ││
│ │ Signification: Feedback positif, pas que critique ││
│ │ Responsabilité réviseur: Être genuín, pas condescendant ││
│ │ Réponse auteur: Aucune nécessaire, fait du bien ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Intégration GitScrum
Suivre Reviews
CONNECTER PR AUX TÂCHES:
┌─────────────────────────────────────────────────────────────┐
│ VISIBILITÉ DANS GITSCRUM │
├─────────────────────────────────────────────────────────────┤
│ │
│ INTÉGRATION GITHUB/GITLAB/BITBUCKET: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. Developer référence tâche dans PR/commit ││
│ │ "Fix timeout login utilisateur [GS-1234]" ││
│ │ ││
│ │ 2. Activité PR apparaît sur tâche GitScrum ││
│ │ Tâche #1234 montre: ││
│ │ • PR ouvert ││
│ │ • Reviews demandés ││
│ │ • Commentaires ajoutés ││
│ │ • Statut merge ││
│ │ ││
│ │ 3. Équipe voit contexte complet sans changer outils ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ AUTOMATION COLONNE WORKFLOW: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Considérer workflow: ││
│ │ ││
│ │ En Dev → En Review → Prêt QA → Terminé ││
│ │ ││
│ │ Colonne "En Review" = PR ouvert, attente approbation ││
│ │ ││
│ │ Déplacer vers En Review quand: ││
│ │ • PR créé et prêt pour review ││
│ │ • Pas encore WIP (draft PR) ││
│ │ ││
│ │ Déplacer vers Prêt QA quand: ││
│ │ • PR approuvé et mergé ││
│ │ • Déployé vers environnement test ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Efficacité Review
Dimensionner PRs Correctement
GUIDES TAILLE PR:
┌─────────────────────────────────────────────────────────────┐
│ PRs PLUS PETITS = MEILLEURS REVIEWS │
├─────────────────────────────────────────────────────────────┤
│ │
│ SEUILS TAILLE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Lignes Changées │ Qualité Review │ Action ││
│ │ ─────────────────┼─────────────────┼────────────────── ││
│ │ < 200 lignes │ ✅ Approfondi │ Taille idéale ││
│ │ 200-400 lignes │ ⚠️ Adéquat │ Acceptable ││
│ │ 400-800 lignes │ ❌ Précipité │ Considérer diviser ││
│ │ > 800 lignes │ ❌ Rubber stamp │ Doit diviser ││
│ │ ││
│ │ Exception: Gros refactors avec patterns clairs ││
│ │ Exception: Code généré ou fichiers config ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ STRATÉGIES DIVISION: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Feature trop grande pour un PR: ││
│ │ ││
│ │ Option 1: Découpage vertical ││
│ │ ┌─────────────────────────────────────────────────────┐ ││
│ │ │ PR 1: Happy path basique (tranche fine end-to-end) │ ││
│ │ │ PR 2: Gestion erreurs │ ││
│ │ │ PR 3: Cas limites │ ││
│ │ │ PR 4: Optimisation performance │ ││
│ │ └─────────────────────────────────────────────────────┘ ││
│ │ ││
│ │ Option 2: Couche par couche ││
│ │ ┌─────────────────────────────────────────────────────┐ ││
│ │ │ PR 1: Schéma base données + migrations │ ││
│ │ │ PR 2: Endpoints API backend │ ││
│ │ │ PR 3: UI frontend │ ││
│ │ │ PR 4: Intégration et tests │ ││
│ │ └─────────────────────────────────────────────────────┘ ││
│ │ ││
│ │ Suivre dans GitScrum: ││
│ │ Tâche principale avec sous-tâches pour chaque PR ││
│ │ Lier tous PRs à tâche parente pour visibilité ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘