1

Les revues de code ou comment faire fructifier son capital humain

Passionné de web depuis 1996, de PHP depuis 2000 et de musique depuis 1977

Jean-Marc Fontaine

Responsable de la qualité logicielle chez Profilsoft

3

Kezako ?Les revues de code

Une revue de code consiste à examiner le code de quelqu'un d'autre à la recherche de défauts ou d'améliorations potentielles

Il n’y a pas une application pour ça ?Outils d'analyse

‣ 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

Tests unitaires, fonctionnels, <insérez un buzzword ici>, etc.Et les tests automatisés ?

‣ 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

Choisissez bien, choisissez le but !But des revues de code

‣ Amélioration de la qualité du code

‣ Vérification de la conformité

‣ Vérification de l'exhaustivité

7

Parce qu’il n’y a pas de petit profitBénéfices indirects

‣ Partage de la connaissance

‣ Formation des juniors

‣ Amélioration de la maîtrise collective du code

‣ Émergence d'idées neuves

8

Parce qu’il y a toujours des gens contre…Objections habituelles

‣ Coût

‣ Perte de temps

‣ Freins humains

‣ Difficultés d'organisation

‣ Méthode non exhaustive

9

Encore un truc de hispter qui mange bio !C'est un truc expérimental ?!

‣ 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

Pre-commitA quel moment ?

12

‣ Assure la qualité du code commité

‣ Peut être bloquant si les auditeurs ne sont pas disponibles

Post-commitA quel moment ?

13

‣ 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

Constituer l’équipe

‣ Entre 3 et 7 personnes

‣ Rôles• Auteur• Inspecteur• Modérateur• Lecteur• Secrétaire • Vérificateur

14

Choisir un lieu

‣ Calme

‣ L'équipe doit rester isolée durant toute la revue

15

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

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

Déroulement

18

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é

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

Livrables

‣ Code retravaillé

‣ Journal des défauts

‣ Compte-rendu de revue

20

21

Évaluer le fruit desrevues de code

Mesures de base

22

‣Nombre de lignes à étudier‣Nombre de lignes étudiéesTaille

‣Planification‣Présentation‣Préparation‣Revue‣Modification

Effort

‣Nombre de défauts mineurs et majeures trouvés‣Nombre de défauts mineurs et majeures corrigésDéfauts

‣Durée de la revue‣Nombre d’inspecteurs‣Evaluation de la qualité du code

Divers

Mesures avancées

23

‣Nombre de défauts par unité de code étudiée‣Nombre total de défauts trouvés‣Nombre total de défauts corrigés

Défauts

‣Nombre d’heures consacrées à la revue dans son ensemble‣Nombre d’heures moyen pour trouvé un défaut (hors correction)‣Nombre d’heures moyen pour inspecter une unité de code

Effort

‣Pourcentage du code prévu qui a été effectivement revu‣Pourcentage de défauts considérés comme majeursCouverture

‣Nombre moyen d’unités de code inspectées par revue‣Nombre moyen d’heures de préparation individuelle par unité de code‣Nombre moyen d’heures pour corriger et vérifier un défaut

Rythme

24

Outiller sesrevues de code

Outils Open Source

25

‣ Review Board

‣ Gerrit

‣ Github

Outils commerciaux

‣ SmartBear Code Collaborator

‣ Atlassian Crucible

26

Ca aurait de l’allure gravé sur une pierre, non ?10 commandements

‣ 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

Merci !

‣ jmfontaine.net

‣ @jmfontaine

‣ jm@jmfontaine.net

28