revue de code - php tour nantes 2012
DESCRIPTION
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.TRANSCRIPT
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
28