Les codes reviewztraminer
Morgane H
@Nazcange
Dev Front
Qu'est-ce qu'un code review et à quoi ça sert ?
Définition
Le code review est l'examen systématique du code source d'un logiciel / site / application par un ou plusieurs membres de l'équipe.
Pourquoi ?
Après tout je fais du bon code !
- Éviter les bugs
- Corriger des erreurs de conception
- Mettre en place des standards au sein de l'équipe
- Éviter le « bus factor »
- Permettre de monter en compétence
- Améliorer le travail d’équipe
Objectif
Améliorer :
- La qualité
- La maintenabilité
- La sécurité
Les trois Q
Qui / Quand / Quoi | Comment
Qui
Tout le monde
Au moins 2 personnes de l'équipe
Quand
Vous reprendrez bien un peu de Q ?
QUOTIDIEN
- Pour éviter les revues de code qui porteraient sur des milliers de lignes
- Simple & digeste
- Entre deux développements (pour éviter les interruptions)
- Quand c'est assigné
Pas de bras pas de chocolat
Pas de merge sans code review
Quoi / Comment
Les outils existants :
Ou un outil de ticketing/tâche management (trello, redmine, asana, etc)
Tu tires ou tu pointes ?
On apprend mieux quand on corrige soi-même
Tips & conseils
Pas de flash
(seul de très rares élus sont capable de maîtriser le push & merge)
La revue de code ne doit pas porter sur les standards de codage.
La revue doit porter sur la logique et le fonctionnel.
Les PR/MR
Les outils d'intégration continue sont de bons moyens pour savoir si il faut faire la revue ou non.
A plusieurs c'est bien
Mais pas trop non plus
Plusieurs solutions :
- Attribuer la revue de code à tour de rôle
- Réduire le nombre d'intervenant
C'est utile même pour de la correction d'orthographe
Comment convaincre les gens (d'en haut) que c'est nécessaire ?
Les Quatre A :
Argent / Assurance / Amélioration / Agnostique
Argent
- Le nerf de la guerre
- Des économies incontestables
- Image de marque respectée (moins d'anomalies en prod)
- Bonus : planning respecté
Assurance
- On est beaucoup plus serein sur les MeP
- Le code est connu & maintenable par plus d'une personne
Amélioration
- Les bonnes pratiques sont plus facilement partagées
- On apprend mieux de ses erreurs quand elles ne sont pas subies
- On mutualise les "défenses"
Agnostique
- Même processus quelles que soient les technos
- Tous à la même enseigne
Le Figaro en quelques chiffres
- 2 mois pour que toute l'équipe se mette aux CR sur nos projets
- Pas forcément plus long au final que les daily stand up
- 80% d'anomalies en prod en moins
- Cerise sur le gâteau : demain je pars en congés, et vous ?