Télécharger en tant que PDF, PPTX
Téléchargé parEric SIBER
La relecture de code : avant tout des pratiques
La relecture de code est une pratique essentielle pour améliorer la qualité du logiciel et favoriser l'apprentissage au sein des équipes. Elle permet de réduire les défauts, d'augmenter la productivité et de créer un environnement de collaboration. L'efficacité de cette pratique repose sur une approche collective et structurée, intégrée au flux de travail des développeurs.
![[Agile Laval 2016] La relecture de code : avant tout des pratiques](https://cdn.slidesharecdn.com/ss_thumbnails/relecturecodeaagilelaval2016-impression-160630135508-thumbnail.jpg?width=640&height=640&fit=bounds)
![[BreizhCamp 2016] La relecture de code : avant tout des pratiques](https://cdn.slidesharecdn.com/ss_thumbnails/relecturecodeaubreizhcamp2016-160325145850-thumbnail.jpg?width=640&height=640&fit=bounds)
La relecture de code : avant tout des pratiques
- 1. La relecture decode : avant tout des pratiques ! Eric SIBER - @esiber – 13/03/2018
- 2. © Geek &Poke But de la présentation
- 3. Une orientation selonle 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
- 4. Qui suis-je ? Dansle 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
- 5. Qui suis-je ? Dansle 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, Culture Kanban, Agile Laval)
- 6. Qui suis-je ? Actuellementen tant que Consultant indépendant : ● Coach Agile pour Chais d’Oeuvre ● Formateur (Ingénierie pédagogique) pour Webforce3 ● Expert technique pour CAST Où me trouver : ● Sur twitter : @esiber ● Sur mon blog : https://eric.siber.fr/ ● Sur http://www.brownbaglunch.fr/baggers.html#Eric_Siber_Paris
- 7. De quoi va-t-onparler ? ● 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
- 8. Qui estime avoirdéjà fait de la relecture de code ?
- 9. Qui estime avoirdéjà bénéficié d’une relecture de code ?
- 15. Bénéfices attendus ● Qualité ●Apprentissage ● Mentoring ● Partage de la connaissance ● Référentiel de pratiques ● Travail en équipe ● Normalisation ● Confiance
- 17. « After experiencingthe benefits of peer reviews for nearly fifteen years, I would never work in a team that did not perform them »
- 19. « the averageeffectiveness 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 »
- 20. « A studyof 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”
- 21. « In agroup 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”
- 22. SOFTWARE QUALITY TOOLSFOR THE CONNECTED WORLD
- 23. Expérience d’un clientsur 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
- 26. Statistiques ● Intrinsèquement plusefficace que les démarches de tests automatisés ● Légère augmentation de la productivité ● Diminution considérable du taux d’anomalies détectées de la recette jusqu’à la production ● Plus efficace qu’une recette utilisateur pour la détection d’anomalies ● Diminution importante du coût consacré à la correction d’anomalies
- 28. Over The Shoulder – Faceto face
- 29. Typologies de relectureà posteriori
- 30.
- 31. Assisté par unoutil dédié
- 35. Typologies de relecturecourantes ● A posteriori ● Over the shoulder ● Face to face ● Email pass-around ● Assisté par un outil ● Pair-programming
- 36. 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
- 39. Quand relisez vousvotre code ?
- 41.
- 42. ● Sentiment d’envahissement? Comment appréhender d’être relu ? o C’est le code qui est évalué, pas son auteur
- 43. ● Augmentation deses exigences ? o Davantage d’efforts dans la rédaction du code ? Comment appréhender d’être relu ? Source : http://www.tivix.com/blog/everyone-loves-a-good-book/
- 44. ● Attendre ousolliciter la relecture ? o Crainte de la relecture ? o Frustration de ne pas avoir de feedback ? Comment appréhender d’être relu ?
- 45. ● Evaluer lecode, 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 ?
- 46. ● Illustre uneabsence 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 !
- 47. Les aspects humains ●Propriété collective du code ● Responsabilité partagée ● Une question de contexte ● Quand relire ? ● Quand accueillir une relecture ? ● On évalue le code, pas son auteur ● Questionner sur le cheminement à l’origine ● Conseiller plutôt que reprimander ● Communiquer coûte que coûte
- 48. ● Jeu derô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
- 50. ● Un ensemblede ressources remplissant une fonction ? ● Un différentiel lié à la mise en place d’une nouvelle fonctionnalité ? ● Une couche applicative ? ● Etc. Quoi ?
- 51.
- 52. ● 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) ?
- 53. Focus sur lecommit, 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/
- 54. • Moins intrusifqu’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
- 55. Le quand etle quoi sont à confronter à un aspect quantitatif Une tendance • Le plus souvent • La plus petite unité de code (le moins longtemps)
- 56. Le scope dela relecture ● Relecture de code != audit de code ● Identifier l’unité de code à relire / relue ● Code en l’état ● Différentiel ● Clarifier le quand ● Attention aux interruptions d’activités ● Réfléchir au cycle de vie de production de code ● Tendre vers des relectures le plus souvent et de petites unités de code
- 58. Qu’observer sur unerelecture de code à posteriori ? • Ce qui n’est pas déjà couvert par un outil d’analyse statique de code • Ce qui ne peut pas être pris en charge par un outil d’analyse statique de code • Le but est de ne garder que des éléments qualitatifs pour la relecture manuelle : elle doit cibler le fond et non la forme
- 59. Quelques thématiques pourinspirer • Compréhension générale du code (nommage, cohérence nom / comportement, couplage) • Conformité par rapport aux attentes • Respect des principes de programmation • Gestion des exceptions • Démarches de tests • Problématiques de performance • Problématiques de droits / sécurité • Adoption et homogénéité des normes de développement (ex. XML versus annotations)
- 60. Qu’observer sur unerelecture de code à posteriori ? • Partager une check-list de taille raisonnable pour guider la relecture ... et l’écriture • Le listing est utile à l’auteur et au relecteur • La maturité aidant, deux sous-listes peuvent émerger • Liaison avec l’agilité (Definition of Done) • Il n’est pas interdit d’exploiter la qualimétrie pour guider une session de relecture de code
- 61. A quoi s’intéressersur une relecture ● Bien distinguer la relecture automatique de la relecture manuelle ● Priorité de la relecture automatique : le fond ● Priorité de la relecture manuelle : la forme ● Faire écho aux normes de développement ● Intrinsèques aux frameworks / librairies ● Celles adoptées par l’équipe ● Responsabiliser autant auteur et relecteur ● Principe de check-list(s)
- 63. Respect du code ●Le résultat des relectures ne le surcharge pas ● Le code conserve sa lisibilité naturelle
- 67. Facteurs clés desuccès ● Respect du code : non envahi par les traces des relectures ● L’importance de la visualisation ● Centralisation et historisation des relectures ● Définition / renforcement d’un workflow de travail Ne pas oublier le facteur humain
- 69. Ce qui afait é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
- 70. 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)
- 71. Conclusions La relecture decode ● s’inscrit dans une démarche qualité => objectifs ● se décline sous diverses formes => process ● est plus efficace incluse au flux de travail ● est une démarche d’équipe qui requiert courage et respect => valeurs XP L’outil est un moyen / support à la démarche ● N’est pas une fin en soit ● Ne doit pas imposer le processus de relecture ● Nécessite de clarifier sa place dans le process
- 72. La pratique s’inscritdans un tout cohérent et créateur de valeur
- 74.
- 75.
- 76.
- 77.
- 78. • What iscode review • Better code starts with review (infographie) • 11 proven practices for more effective, efficient peer code review
- 79. La relecture decode : avant tout des pratiques ! Eric SIBER - @esiber