A la découverte de la revue de code

Tout au long d'un projet logiciel, les équipes de développeurs & développeuses sont confrontées à la problématique suivante : comment produire un code évolutif, facile à maintenir et compréhensible ? Chaque personne qui développe possède une expérience, un parcours et une formation qui lui sont propres. Il est donc logique qu'au sein d'une équipe, tout le monde ait naturellement sa propre façon de faire et ses propres méthodologies pour programmer. Si tout cela constitue indéniablement une richesse, il convient néanmoins de considérer le code d'un projet comme une propriété collective sur laquelle on doit apporter une attention particulière pour en préserver la cohérence, mais aussi pour livrer fréquemment en évitant les régressions.

Dès lors, plusieurs questions se posent :

Comment s'assurer que le code que je viens d'écrire respecte les bonnes pratiques définies sur le projet ?
Comment savoir si la prochaine personne qui relira le code sera en capacité de le comprendre ?
Quelles sont les possibilités pour l'améliorer ?
Si il existe plusieurs approches pour répondre à ces défis, plusieurs solutions se trouvent dans les pratiques plébiscités par l'Extreme Programming (XP), et parmi elles, la revue de code est une piste à étudier.

Cette présentation une introduction à la revue de code dans une équipe. Nous évoquons les principes généraux, les objectifs visés, les bonnes pratiques à mettre en œuvre et erreurs à éviter, sans oublier le comportement et le savoir-être nécessaire dans un tel exercice de communication.

Nous présentons plusieurs cas d'usage et comment Promyze, outil d'aide à la définition des bonnes pratiques, exploite les mécanismes de la revue de code en équipe.

Transcript

1. A la découverte de la revue de code 19 Nov. 2020 Code Clean
2. 2 Nos activités depuis 2016 : • Editeur de logiciel • Conseil en stratégie de qualité logicielle • Atelier de développement logiciel 11 Personnes Weʼre from Bordeaux !
3. 3 La Revue de code ! Motivations et objectifs Mise en œuvre Bonnes pratiques et Erreurs à éviter Définir ses pratiques grâce à la revue
4. 4 Lʼobjectif premier de la revue ? Identifier les bugs au plus tôt Source : Octo
5. 5 Focus : Etat de lʼart The Impact of Code Review Coverage and Code Review Participation on Software Quality – MSR 2014 – Shane McIntosh et al. “Components with higher review coverage tend to have fewer post-release defects.” Design and code inspections to reduce errors in program development – 1976 – IBM - Michael Fagan 60 % des défauts trouvés pendant une revue de code
6. 6 Quelles motivations ? Maintenir une base de code propre et compréhensible Augmenter la connaissance du code et consolider la propriété collective Assurer le suivi des conventions et des standards dans lʼorganisation Renforcer la cohésion dʼéquipe
7. 7 Focus : Etat de lʼart Modern Code Review: A Case Study at Google, Sadowski et al. ICSE-SEIP ʼ18
8. 8 Comment sʼassurer que la revue de code ait des bénéfices ? Quels prérequis avant de démarrer ?
9. 9 Avant de commencer : partageons la même vision Ce quʼest la revue : • Une façon dʼaméliorer la qualité du logiciel quʼon produit • Un très bon exercice de communication • Un moment de partage entre membres dʼune équipe Ce que ne doit pas être la revue : • Un moment dʼangoisse pour les développeurs • Une contrainte ou une charge supplémentaire • Un défouloir pour régler les problèmes au sein de lʼéquipe
10. 10 Les 10 Commandements de lʼegoless programming Comprendre et accepter que nous ferons des erreurs Vous nʼêtes pas votre code Quel que soit notre niveau dʼexpertise, quelquʼun dʼautre en saura toujours plus Ne pas réécrire le code de quelquʼun sans le consulter Traiter ceux qui en savent le moins avec respect et patience La seule constante au monde est le changement La seule autorité acceptable vient de la connaissance, non du pouvoir Il faut se battre pour ses idées mais accepter la défaite Ne pas être « lʼinformaticien du bureau du fond » Critiquer le code plutôt que la personne The Psychology of Computer Programming ,1971 Humilité, Empathie, Savoir-être, Ouverture dʼesprit
11. 11 Comment sʼassurer que la revue de code ait des bénéfices ? Bonnes pratiques & Erreurs à éviter
12. 12 « Less is more » Limiter la taille (400 lignes max.) Faire une revue en vitesse Ne pas rester superficiel Relire du code sans être « focus »
13. 13 Il y a un humain derrière un code Faire preuve de savoir-être et dʼempathie Formuler des remarques constructives Suggérer plutôt quʼimposer Faire du « bashing » dans lʼopen-space Oublier de valoriser le travail bien fait Crédits : Geek & Poke
14. 14 Délimiter un cadre Définir la portée des revues de code Lancer des débats plus larges Pinailler / Parler pour parler Sʼaccorder sur une check-list
15. 15 Une rigueur nécessaire des deux côtés “Clean code always looks like it was written by someone who cares.” Robert C. Martin Points à vérifier avant de soumettre : • Respect des conventions, • Tests unitaires OK, • Envisager les cas possibles (null, listes vides, …) • Clarté du code Assumer que lʼautre détectera « de toute manière » les problèmes
16. 16 Et la restitution ? Présenter ses retours à lʼoral Corriger en pair programming si besoin La revue est avant tout un exercice de communication Corriger à la place de lʼauteur
17. 17 Qui relit dans une équipe ? Souvent, des profils en « Lead Technique » Tout le monde devrait éprouver le rôle de relecteur On peut apprendre de chaque personne dans lʼéquipe On peut toujours sʼaméliorer grâce aux connaissances des autres
18. 18 Facteurs qui influencent la qualité dʼune revue Code review Quality : How Developers See It – ICSE 2016
19. 19 Formats de revue de code • Revue par un pair => En continue, A la fin dʼune User Story (ou en cours si trop grosse) • Pair programming => Début de User Story, Code complexe, Nouvelle recrue, … • Revue collective => Code cœur métier, nouvelles technos, bonnes pratiques Ratez vos revues de code en 5 leçons ! (Michel Domenjoud, Devoxx – 2016)
20. 20 Aller plus loin avec la revue de code Que fait-on lors dʼune revue ? • Analyse fine du code • Identification de problèmes • Valorisation du travail bien réalisé • Propositions dʼaméliorations • Discussions avec dʼautres développeurs Comment exploiter davantage ces mécanismes ? Chez Promyze, nous avons eu une idée…
21. 21 La revue collective pour construire notre ensemble de bonnes pratiques Comment définir nos bonnes pratiques de développement ? Comment les faire émerger au sein de lʼéquipe ? Comment les documenter et les rendre accessible ? Comment aider une équipe à prendre des décisions ?
22. @ProMyze 22 Atelier Craft : Comment ça marche ? 1 2 3 4 Sélection des fichiers Quelques fichiers suffisent pour démarrer un atelier. Le choix sʼeffectue selon la thématique définie pour lʼatelier. Promyze vous aide à identifier des fichiers récemment modifiés par lʼéquipe. Identification des pratiques Chaque développeur identifie dans les fichiers des bonnes pratiques (qui sont suivies ou non), à partir de pratiques existantes ou de nouvelles qui ne sont pas encore dans la liste. Discussions lors des rétrospectives Chacun va présenter les pratiques identifiées dans les fichiers. Si une nouvelle pratique est proposée, elle doit être validée par lʼéquipe. Les exemples et contre-exemples illustreront ces pratiques. Centralisation des bonnes pratiques Votre liste de bonnes pratiques définies en équipe avec les exemples présents directement dans votre code se retrouve dans Promyze. Les pratiques sont rangées en profils par faciliter la navigation.
23. 23 Prêt-e-s à embarquer ? https://app.promyze.com
24. Contact cedric.teyton@promyze.com https://promyze.com QUESTIONS ? @ProMyze @ProMyze_QL