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

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

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

RDV à Agile France 2016
http://lanyrd.com/2016/agilefrance/

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

Recomendados

Recomendados

Más contenido relacionado

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

Similar a [BreizhCamp 2016] La relecture de code : avant tout des pratiques (20)

Más de Eric SIBER

Más de Eric SIBER (10)

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