Revue de code - PHP Tour Nantes 2012
Upcoming SlideShare
Loading in...5
×
 

Revue de code - PHP Tour Nantes 2012

on

  • 1,952 views

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 ...

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.

Statistics

Views

Total Views
1,952
Views on SlideShare
1,943
Embed Views
9

Actions

Likes
2
Downloads
19
Comments
0

1 Embed 9

https://twitter.com 9

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Revue de code - PHP Tour Nantes 2012 Revue de code - PHP Tour Nantes 2012 Presentation Transcript

    • Les revues de code ou comment faire fructifier son capital humain 1
    • Jean-Marc FontainePassionné de web depuis 1996, de PHP depuis 2000 et demusique depuis 1977 Responsable de la qualité logicielle chez Profilsoft
    • 3
    • Les revues de codeKezako ? Une revue de code consiste à examiner le code de quelquun dautre à la recherche de défauts ou daméliorations potentielles
    • 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
    • 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
    • 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
    • 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
    • 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
    • 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
    • Organiser une revue de code 11
    • A quel moment ?Pre-commit ‣ Assure la qualité du code commité ‣ Peut être bloquant si les auditeurs ne sont pas disponibles 12
    • 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
    • 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 lapplication‣ 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 dopportunités doptimisations 17
    • 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
    • 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
    • Livrables‣ Code retravaillé‣ Journal des défauts‣ Compte-rendu de revue 20
    • Évaluer le fruit des revues de code 21
    • 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
    • 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
    • Outiller sesrevues de code 24
    • Outils Open Source‣ Review Board‣ Gerrit‣ Github 25
    • Outils commerciaux‣ SmartBear Code Collaborator‣ Atlassian Crucible 26
    • 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
    • Merci !‣ jmfontaine.net‣ @jmfontaine‣ jm@jmfontaine.net 28