[Agile Laval 2016] La relecture de code : avant tout des pratiques

#AgileLaval16#codeReview

La relecture de code : avant tout des pratiques !

Eric SIBER - @esiber

Merciànossponsorsetànospartenaires

#AgileLaval16

© Geek & Poke

#AgileLaval16 #codeReview @esiber

But de la présentation

Une orientation selon le manifeste agile :

●  Les individus et leurs interactions plus que les processus et les outils

●  Des logiciels opérationnels plus qu’une documentation exhaustive

●  La collaboration avec les clients plus que la négociation contractuelle

●  L’adaptation au changement plus que le suivi d’un plan


Qui suis-je ?


Dans le monde du service en IT, en Région Parisienne depuis plus de 10 ans : ●  Agile Java Craftsman ●  Creative Ecosystem Organizer ●  Runner et Papa 2.0

Qui suis-je ?

Dans le monde du service en IT, en Région Parisienne depuis plus de 10 ans : ●  Agile Java Craftsman ●  Creative Ecosystem Organizer ●  Runner et Papa 2.0

Sur le plan communautaire : ●  Membre actif, modérateur, rédacteur et responsable

bénévole Java sur Developpez.com de 2005 à 2009 ●  Co-organisateur de la conférence Agile France en 2013 ●  Interventions en conférence (Scrum Day, Agile Toulouse,

Breizhcamp, Agile France) #AgileLaval16 #codeReview @esiber

De quoi va-t-on parler ?

●  Bénéfices attendus ●  Quelques statistiques ●  Typologies de relectures ●  Aspects humains ●  Scope de la relecture (le quoi, le quand) ●  Facteurs clés de succès ●  Eléments disruptifs ●  Quelques références


Qui estime avoir déjà fait de la relecture de code ?


Qui estime avoir déjà bénéficié d’une relecture de code ?








«A"erexperiencingthebenefitsofpeerreviewsfornearlyfi*eenyears,Iwouldneverworkinateamthatdidnotperformthem»




« the average effectiveness of design and code inspections are 55 and 60 percent »

« software testing alone has limited effectiveness -- the average defect detection

rate is only 25 percent for unit testing, 35 percent for function testing, and 45 percent for

integration testing »


« A study of an organization at AT&T with more than 200 people reported a 14 percent

increase in productivity and a 90 percent decrease in defects after the organization

introduced reviews. »

Source : “Code Complete”


« In a group of 11 programs developed by the same group of people, the first 5 were developed without reviews. The remaining 6 were developed with reviews. After all the programs were released to production, the first 5 had an average of 4.5 errors per 100 lines of code. The 6 that had been inspected had an average of only 0.82 errors per 100. Reviews cut the errors by over 80 percent. »

Source : “Code Complete”


SOFTWARE QUALITY TOOLS FOR THE CONNECTED WORLD


Expérience d’un client sur un projet de 10 000 LOC avec 10 développeurs : ●  les anomalies détectées par l’homologation et les utilisateurs

sur une période de 6 mois ont été consignées ●  un groupe de développeur a fait une revue de code sur la

même base de code initial et a identifié 162 bugs supplémentaires

●  d’après des métriques ils ont estimé que la revue de code aurait pu réduire de 50% le coût de correction des anomalies

Source:BestKeptSecretsofPeerCodeReview



Over The Shoulder –

Face to face


Typologies de relecture à posteriori


Email pass around


Assisté par un outil dédié #AgileLaval16 #codeReview @esiber




Typologies de relecture : variantes

●  Réunions de type revue / relecture de code ●  Plusieurs intervenants (de 3 à 6) ●  Différents rôles attribués ●  « Formal Inspections » (défini comme une 5ème typologie

dans Best Kept Secrets of Peer Code Review) ●  Mob Programming ●  Remote Pair-programming ●  Partage de bureau à distance ●  VS Anywhere ●  Eclipse Saros



Propriété collective du code (collective ownership) Responsabilité partagée


Quand relisez vous votre code ?




●  Sentiment d’envahissement ?

Comment appréhender d’être relu ?

o  C’est le code qui est évalué, pas son auteur



Source:h@p://www.Cvix.com/blog/everyone-loves-a-good-book/


●  Augmentation de ses exigences ? o  Davantage d’efforts dans la rédaction du

code ?



●  Attendre ou solliciter la relecture ?

o  Crainte de la relecture ? o  Frustration de ne pas avoir de feedback ?



●  Evaluer le code, pas son auteur ●  Poser des questions

○  Chercher à comprendre le raisonnement suivi ○  Eviter le « pourquoi » trop accusateur

●  Conseiller plutôt que réprimander ●  Ne pas chercher systématiquement à

imaginer comment on aurait fait soi même

○  Il y toujours plusieurs solutions à un problème

Comment s’y prendre pour relire ?


●  Illustre une absence de pédagogie ●  Justifié ou non, l’auteur initial n’aura rien

appris et continuera à faire ce type d’erreur ●  Risque de conflit et de défiance / compétition

Les dérives de la modification directe du code

Ces conseils peuvent s’appliquer hors revue de code !


●  Jeu de rôle pour le candidat o  Relire un code existant qu’on lui présente o  Subir la relecture sur un code qu’il a produit o  Situation de Pair-programming

●  Les aspects humains comptent pour 50%, autant que les aspects techniques

L’exercice de relecture peut s’appliquer dans le cadre d’un entretien de recrutement



●  Un ensemble de ressources remplissant une fonction ?

●  Un différentiel lié à la mise en place d’une nouvelle fonctionnalité ?

●  Une couche applicative ? ●  Etc.

Quoi ?



●  Projet terminé ? ●  Fonctionnalité livrée sur un environnement

donné ? ●  Itération de développement terminée ? ●  Développement d’une fonctionnalité

complète terminée ? ●  Code propagé ?

Quand (dans le cycle de vie) ?


Focus sur le commit, 2 nuances à considérer •  Pre-commit review •  Post-commit review

Quand (dans le cycle de vie) ?

Source:h@p://devmag.fr/pourquoi-il-vous-faut-adopter-les-pull-requests/


•  Moins intrusif qu’une intervention sur une anomalie de production (sauf s’il faut relire la correction)

•  L’impact est lié au workflow employé

Ne pas négliger l’interruption de l’activité courante


Le quand et le quoi sont à confronter à un aspect quantitatif

Une tendance •  Le plus souvent •  La plus petite unité de code (le moins

longtemps)



Respect du code ●  Le résultat des relectures ne le surcharge

pas ●  Le code conserve sa lisibilité naturelle






Ce qui a fait évoluer les pratiques dans le passé récent

•  Les DVCS (ex. Git) et l’apparition de workflows de développement

•  Les interactions avec les plateformes d’intégration continue (PIC)

•  Le Cloud comme support aux 2 outils précédemment mentionnés


Quelques prédictions / tendances pour l’avenir (déjà bien en route)

•  Elaboration de solutions ALM complètes o  Poussé par la tendance Cloud o  Favorisé par l’évolution des technologies Web tel HTML5

•  Percée des Web-IDE o  Encore davantage d’interactions o  Favorisé par l’évolution des technologies Web tel HTML5

•  Solutions de type realtime sharing (ex. Google Docs)



hDp://www.amazon.com/Code-Complete-PracJcal-Handbook-ConstrucJon/dp/0735619670/


hDp://www.amazon.com/Peer-Reviews-SoSware-PracJcal-Guide/dp/0201734850/


hDp://www.amazon.fr/The-Psychology-Computer-Programming-Anniversary/dp/0932633420


hDp://www.amazon.com/Best-Kept-Secrets-Peer-Review/dp/1599160676hDp://smartbear.com/SmartBear/media/pdfs/best-kept-secrets-of-peer-code-review.pdf


#AgileLaval16#codeReview

La relecture de code : avant tout des pratiques !

Eric SIBER - @esiber

Software

[Agile Laval 2016] La relecture de code : avant tout des pratiques