Revue de code - PHP Tour Nantes 2012

2,279 views
2,158 views

Published on

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.

Published in: Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
2,279
On SlideShare
0
From Embeds
0
Number of Embeds
85
Actions
Shares
0
Downloads
24
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Revue de code - PHP Tour Nantes 2012

  1. 1. Les revues de code ou comment faire fructifier son capital humain 1
  2. 2. Jean-Marc FontainePassionné de web depuis 1996, de PHP depuis 2000 et demusique depuis 1977 Responsable de la qualité logicielle chez Profilsoft
  3. 3. 3
  4. 4. Les revues de codeKezako ? Une revue de code consiste à examiner le code de quelquun dautre à la recherche de défauts ou daméliorations potentielles
  5. 5. Outils danalyseIl n’y a pas une application pour ça ? ‣ Complémentaires ‣ Adaptés aux problèmes de syntaxe et doptimisation subtile ‣ Pas adaptés aux problèmes fonctionnels ou de logique ‣ Un humain est plus doué qu’une machine 5
  6. 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. 7. But des revues de codeChoisissez bien, choisissez le but ! ‣ Amélioration de la qualité du code ‣ Vérification de la conformité ‣ Vérification de lexhaustivité 7
  8. 8. Bénéfices indirectsParce 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 didées neuves 8
  9. 9. Objections habituellesParce qu’il y a toujours des gens contre… ‣ Coût ‣ Perte de temps ‣ Freins humains ‣ Difficultés dorganisation ‣ Méthode non exhaustive 9
  10. 10. Cest 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 nest commité sans être revu au préalable. 10
  11. 11. Organiser une revue de code 11
  12. 12. A quel moment ?Pre-commit ‣ Assure la qualité du code commité ‣ Peut être bloquant si les auditeurs ne sont pas disponibles 12
  13. 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. 14. Constituer l’équipe‣ Entre 3 et 7 personnes‣ Rôles • Auteur • Inspecteur • Modérateur • Lecteur • Secrétaire • Vérificateur 14
  15. 15. Choisir un lieu‣ Calme‣ Léquipe doit rester isolée durant toute la revue 15
  16. 16. Sélectionner le code à étudier‣ Systématique‣ À la demande du développeur‣ Parties problématique de lapplication‣ Couverture de code‣ Expérience‣ Hasard 16
  17. 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 dopportunités doptimisations 17
  18. 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. 19. Après la revue de code‣ Lauteur modifie son code en fonction du journal des défauts‣ Le modérateur rédige un compte-rendu de revue‣ Le vérificateur sassure que le code a été retravaillé comme convenu 19
  20. 20. Livrables‣ Code retravaillé‣ Journal des défauts‣ Compte-rendu de revue 20
  21. 21. Évaluer le fruit des revues de code 21
  22. 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. 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. 24. Outiller sesrevues de code 24
  25. 25. Outils Open Source‣ Review Board‣ Gerrit‣ Github 25
  26. 26. Outils commerciaux‣ SmartBear Code Collaborator‣ Atlassian Crucible 26
  27. 27. 10 commandementsCa 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. 28. Merci !‣ jmfontaine.net‣ @jmfontaine‣ jm@jmfontaine.net 28

×