Chaque industrie possède un élément clé dans son modèle économique. Dans l'industrie du développement, le facteur de succès est sans conteste le capital humain. Savoir recruter les meilleurs développeurs est une chose difficile mais les amener à réaliser leur plein potentiel l'est tout autant. En ouvrant le code à d'autres développeurs, les revues de code permettent de rompre l'isolement et de partager les connaissances afin de créer des émulations positives au sein des équipes. Nous verrons les gains qu'on peut attendre de cette pratique, les différentes formes (formelles, itératives, pair programming, etc.) qu'elle peut prendre ainsi que les écueils à éviter pour en tirer pleinement parti.

1. Les revues de code ou comment faire
fructifier son capital humain
1

2. Jean-Marc Fontaine
Passionné de web depuis 1996, de PHP depuis 2000 et de
musique depuis 1977
Responsable de la qualité logicielle chez
Profilsoft

3. 3

4. Les revues de code
Kezako ?
Une revue de code consiste à examiner le code
de quelqu'un d'autre à la recherche de défauts
ou d'améliorations potentielles

5. Outils d'analyse
Il n’y a pas une application pour ça ?
‣ Complémentaires
‣ Adaptés aux problèmes de syntaxe et
d'optimisation subtile
‣ Pas adaptés aux problèmes fonctionnels ou de
logique
‣ Un humain est plus doué qu’une machine
5

6. Et les tests automatisés ?
Tests unitaires, fonctionnels, <insérez un buzzword ici>, etc.
‣ Ils n’indiquent rien de la qualité et de la
maintenabilité du code
‣ Ils trouvent les symptômes tandis que les
revues de code trouvent les causes des
problèmes
6

7. But des revues de code
Choisissez bien, choisissez le but !
‣ Amélioration de la qualité du code
‣ Vérification de la conformité
‣ Vérification de l'exhaustivité
7

8. Bénéfices indirects
Parce qu’il n’y a pas de petit profit
‣ Partage de la connaissance
‣ Formation des juniors
‣ Amélioration de la maîtrise collective du code
‣ Émergence d'idées neuves
8

9. Objections habituelles
Parce qu’il y a toujours des gens contre…
‣ Coût
‣ Perte de temps
‣ Freins humains
‣ Difficultés d'organisation
‣ Méthode non exhaustive
9

10. C'est un truc expérimental ?!
Encore un truc de hispter qui mange bio !
‣ Les revues de code sont pratiquées par tous
les acteurs importants
‣ Chez Google rien n'est commité sans être revu
au préalable.
10

11. Organiser une revue de code
11

12. A quel moment ?
Pre-commit
‣ Assure la qualité du code commité
‣ Peut être bloquant si les auditeurs ne sont pas
disponibles
12

13. A quel moment ?
Post-commit
‣ Pas de blocage
‣ Présence dans le dépôt de code en attente de
revue
‣ Pas forcément un problème si branche dédiée
13

14. Constituer l’équipe
‣ Entre 3 et 7 personnes
‣ Rôles
• Auteur
• Inspecteur
• Modérateur
• Lecteur
• Secrétaire
• Vérificateur
14

15. Choisir un lieu
‣ Calme
‣ L'équipe doit rester isolée durant toute la revue
15

16. Sélectionner le code à étudier
‣ Systématique
‣ À la demande du développeur
‣ Parties problématique de l'application
‣ Couverture de code
‣ Expérience
‣ Hasard
16

17. Préparer une revue
‣ Réunion de présentation
‣ Définition des règles, standards et
spécifications en vigueur
‣ Le lecteur doit se familiariser avec le code
‣ Les inspecteurs doivent étudier le code à la
recherche de problèmes et d'opportunités
d'optimisations
17

18. Déroulement
Le modérateur conduit la revue
Le lecteur décrit le code avec ses mots
Les inspecteurs questionnent et proposent des améliorations
Le secrétaire note les remarques dans le journal
Les inspecteurs notent la qualité du code étudié
18

19. Après la revue de code
‣ L'auteur modifie son code en fonction du
journal des défauts
‣ Le modérateur rédige un compte-rendu de
revue
‣ Le vérificateur s'assure que le code a été
retravaillé comme convenu
19

20. Livrables
‣ Code retravaillé
‣ Journal des défauts
‣ Compte-rendu de revue
20

21. Évaluer le fruit des
revues de code
21

22. Mesures de base
‣Nombre de lignes à étudier
Taille ‣Nombre de lignes étudiées
‣Planification
‣Présentation
Effort ‣Préparation
‣Revue
‣Modification
‣Nombre de défauts mineurs et majeures trouvés
Défauts ‣Nombre de défauts mineurs et majeures corrigés
‣Durée de la revue
Divers ‣Nombre d’inspecteurs
‣Evaluation de la qualité du code
22

23. Mesures avancées
‣Nombre de défauts par unité de code étudiée
Défauts ‣Nombre total de défauts trouvés
‣Nombre total de défauts corrigés
‣Nombre d’heures consacrées à la revue dans son ensemble
Effort ‣Nombre d’heures moyen pour trouvé un défaut (hors correction)
‣Nombre d’heures moyen pour inspecter une unité de code
‣Pourcentage du code prévu qui a été effectivement revu
Couverture ‣Pourcentage de défauts considérés comme majeurs
‣Nombre moyen d’unités de code inspectées par revue
Rythme ‣Nombre moyen d’heures de préparation individuelle par unité de code
‣Nombre moyen d’heures pour corriger et vérifier un défaut
23

24. Outiller ses
revues de code
24

25. Outils Open Source
‣ Review Board
‣ Gerrit
‣ Github
25

26. Outils commerciaux
‣ SmartBear Code Collaborator
‣ Atlassian Crucible
26

27. 10 commandements
Ca aurait de l’allure gravé sur une pierre, non ?
‣ Ne pas étudier plus de 300 lignes à la fois
‣ Adopter un rythme de 300 à 500 lignes étudiées par heure
‣ Ne pas dépasser 90 minutes pour une revue
‣ Les inspecteurs doivent étudier le code avant la réunion de revue
‣ Établir des objectifs quantifiables et recueillir des mesures
‣ Utiliser des checklists
‣ Vérifier que les problèmes trouvés sont effectivement corrigés
‣ Développer la culture de la revue de code
‣ Jouer sur la pression sociale
‣ Éviter le sentiment de surveillance
27

28. Merci !
‣ jmfontaine.net
‣ @jmfontaine
‣ jm@jmfontaine.net
28