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

BreizhCamp 2016 #BzhCmp

#codeReview #BzhCmp

BreizhCamp 2016 #codeReview #BzhCmp

La relecture de code : avant tout des pratiques !

Eric SIBER - @esiber

@esiber

But de la présentation

© Geek & Poke

BreizhCamp 2016 #codeReview #BzhCmp @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 développement en Région Parisienne depuis plus de 10 ans, actuellement : ●  Agile Java Craftsman chez Novedia, groupe VISEO ●  Creative Ecosystem Architect pour VISEO Technologies ●  Runner et Papa 2.0

Qui suis-je ?


Dans le monde du développement en Région Parisienne depuis plus de 10 ans, actuellement : ●  Agile Java Craftsman chez Novedia, groupe VISEO ●  Creative Ecosystem Architect pour VISEO Technologies ●  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

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


L’audience ...


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

L’audience ...


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

Bénéfices attendus










Quelques statistiques


Statistiques : ils en parlent

After experiencing the benefits of peer reviews for nearly fifteen years, I would never work in a team that did not perform them








“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 : Best Kept Secrets of Peer Code Review

Typologies de relecture


Typologies de relecture à posteriori


Over The Shoulder – Face to face





Email pass around


Assisté par un outil dédié








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


Les aspects humains


Les aspects humains


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

Quand relisez vous votre code ?



Quand acceptez vous une relecture ?


Quand acceptez vous une relecture ?

Aspects humains

●  Sentiment d’envahissement ?


Comment appréhender d’être relu ?

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

Aspects humains

●  Augmentation de ses exigences ?



Source : http://www.tivix.com/blog/everyone-loves-a-good-book/

o  Davantage d’efforts dans la rédaction du code ?

Aspects humains

●  Attendre ou solliciter la relecture ?

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



Aspects humains

●  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 ?

Aspects humains

●  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 !

Le scope de la relecture



●  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 : http://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)

Facteurs clés de succès



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

pas ●  Le code conserve sa lisibilité naturelle




L’importance de la visualisation



L’importance de la visualisation



Centralisation et conservation d’un historique des relectures



Définition / renforcement d’un workflow de travail

Eléments disruptifs




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)

Références


Références


http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/

Références


http://www.amazon.com/Peer-Reviews-Software-Practical-Guide/dp/0201734850/

Références


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

Références


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

BreizhCamp 2016 #BzhCmp

#codeReview #BzhCmp

BreizhCamp 2016 #codeReview #BzhCmp

La relecture de code : avant tout des pratiques !

Eric SIBER - @esiber

@esiber

RDV à Agile France 2016


http://lanyrd.com/2016/agilefrance/