La revue de code : facile !

2,891 views
2,596 views

Published on

Presentation faite à Agile France en 2011

La revue de code : c’est facile !

Cette présentation est la suite de la session « La revue de code : c’est agile, c’est lean, c’est indispensable ! » présentée à Agile France et Agile Tour en 2010.
Après avoir répondu aux idées reçues sur la revue de code et avoir montré combien une revue de code systématique soutient une démarche agile et lean, cette présentation se focalise sur la mise en place de la revue de code comme étape incontournable du processus de développement.
Nous évoquerons les bonnes pratiques, les difficultés à la mise en place, les pièges à éviter et aussi les outils qui facilitent la revue de code. Une grande partie de la présentation sera dédiée à plusieurs démonstrations, exemples et retours d’expérience.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
2,891
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

La revue de code : facile !

  1. 1. La revue de code : c’est facile !Lucian PrecupLucian Precupconf.agile‐france.org2011‐05‐27
  2. 2. Lucian PrecupLucian Precup• Développeur, architecte, chef de projets et responsable des développements (Java EE, p pp (ETL, BI)• Consultant en industrialisation des• Consultant en industrialisation des développements (outils ALM, méthodes de é l )développement, organisation)
  3. 3. Qu’est ce la revue de code?Qu est‐ce la revue de code?I i é i d d• Inspection systématique du code source• Mécanisme pour: – Valider le design et l’implémentation des changements– Assurer une cohérence entre modules et développeurs au niveau du design et des pratiques de développementniveau du design et des pratiques de développement– Partager, former et se former• Types de revue de code• Types de revue de code– Formelle ou informelle, pré ou post commit– « Over‐the‐shoulder » par e‐mail« Over the shoulder », par e mail– « Pair‐programming »
  4. 4. AvantagesAvantagesDi t• Directs: – Meilleure qualité du codeMoins de bugs dans le code– Moins de bugs dans le code– Meilleure communication dans l’équipe– Formation des nouveaux arrivants et juniors– Formation des nouveaux arrivants et juniors• Indirects: – Cycle de développement/test plus courts– Cycle de développement/test plus courts– Moins d’impact sur le support technique– Clients plus satisfaitsClients plus satisfaits– Code plus maintenable– Meilleure architecture du code
  5. 5. Objectif de la présentationObjectif de la présentation• Mise en place de la revue de code comme étape incontournable du processus de p pdéveloppement– Les bonnes pratiques– Les bonnes pratiques– Les pièges à éviter– Exemples– Retours d’expérience
  6. 6. La revue de code dans le cycle de développementBesoinsAnalyse techniqueTests unitairesDéveloppementRevue pré‐commitéIntégrationBuild & LivraisonRevue post‐commitTests fonctionnelsDéploiement
  7. 7. Qui implémente la revue de code?Qui implémente la revue de code?
  8. 8. Le monde Open SourceLe monde Open SourceReviewRefactoringRefactoringModificationspatchpatchSCMCIpatchcheckinRMSuper Reviewcheckin
  9. 9. Implémentations et témoignagesImplémentations et témoignagesf di• INRIA Transfert et Medience– Implémentation avec Aegis– Très bonne qualité malgré le turn‐over de l’équipe• Business Objects– « Les développements de l’équipe« Les développements de l équipe Data Federator étaient plus longs. En revanche, ils se stabilisaient rapidement et les délais de livraisons étaient très prévisibles »
  10. 10. Autres témoignagesAutres témoignagesG d édi d l i i l• Grand éditeur de logiciel– Équipe de huit personnes (France et Etats Unis)– Très productive grâce à la revue asynchrone pendant la « nuit »h l• Guido van Rossum, Python creator and Google employee– « As Ive learned over the last two years at Google, … , proper code review habits can really improve the quality of a code base and good tools for code reviewquality of a code base, and good tools for code review will improve developers life »
  11. 11. Convaincus ? Convaincues ?Convaincus ? Convaincues ?
  12. 12. Difficultés à la mise en œuvreDifficultés à la mise en œuvreL d dé l• Les egos des développeurs• La difficulté d’intégrer la revue de code dans le processus decode dans le processus de développement– Rassembler les fichiers– Rassembler les fichiers– Programmer la réunion, interrompre quelqu’un ou lire un long e‐mailq q g– Gérer l’historique– Un simple commit c’est tellement plus i l )simple :‐)• Manque de soutien de la hiérarchie
  13. 13. Piège numéro 1 : mauvaise méthodePiège numéro 1 : mauvaise méthodeF i l d d è l it• Faire la revue de code après le commit• Prendre la revue à la légère, regarder le d di lcode « en diagonale »• Laisser traîner les revuesl ’ f i• Interrompre quelqu’un pour  faire une revueS’ d t j à l ê• S’adresser toujours à la même personne pour la revue• Mettre trop de changements en revue• Mettre trop de changements en revue dans le même patch
  14. 14. Piège numéro 2 : le Team LeaderPiège numéro 2 : le Team Leader• Faire la revue de code uniquement par les Tech Leadsp• Ne plus faire d’analyse technique et ne plus rédiger des spécificationsne plus rédiger des spécifications pour les développeurs• Oublier les autres moyens de formation et transfert deformation et transfert de connaissance
  15. 15. Piège numéro 3: le "Review Failed"Piège numéro 3: le  Review FailedA i d "R i F il d"• Avoir peur du "Review Failed"– Pour le reviewer : faire lui‐même les modifications dans le code d’un junior etmodifications dans le code d un junior et archiver sans faire de retour au développeur• Ne pas craindre le "Review Failed"p– Pour le développeur : trop se baser sur le reviewer et ne pas se soucier de la qualité de dson code• Trop aimer le "Review Failed"P l i R t d l’i té ti d’– Pour le reviewer : Retarder l’intégration d’un change à cause des bugs non bloquants pour le change en revueg
  16. 16. Piège numéro 4 : Le reviewer trop assidu• Exiger que tous les points soient corrigés dans le patch qui est en revuecorrigés dans le patch qui est en revue. – Si le code peut être archivé avec un bug connu ou un développement incomplet,connu ou un développement incomplet, créez le bug ou la tâche, archiver le code et passez à la suite• Faire un "Review Failed" pour un bug qui était déjà présent mais pas vu auparavant ou qui na rien à voir avec le code qui est en revue.
  17. 17. Piège numéro 5: les outilsPiège numéro 5: les outilsl d l• Ne pas utiliser des outils – Traçabilité– Planning– Historique• Utiliser uniquement l’email• Trop compter sur les outilsop co pte su es out s– Des outils comme Hudson, Sonar, FindBugs trouvent des bugs et nous apprennent beaucoupg pp p– Mais il ne faut pas oublier le partage de la connaissance
  18. 18. Piège numéro 6 : Miser tout sur le Pair Programmingi i• Le Pair Programming– Revue de code en continu– Très efficace pour trouver des bugs et pour favoriser la connaissance• Mais– L’examinateur – très impliqué dansLexaminateur  très impliqué dans le code– Trop coûteux à implémenterTrop coûteux à implémenter– Présence physique au même endroit
  19. 19. Bonnes pratiques : le processusBonnes pratiques : le processusd l’é d d• Inscrire et documenter l’étape de revue de façon formelle dans le processus de développementdéveloppement– à côté des best‐practices de développement dans le wiki de l’équipe, par exempleq p , p p• Noter le nom du reviewer dans le message de commit– tout comme on note le numéro du bug ou de la tâche• Programmer les revues comme toute autre tâched d l l d h– en stand‐up meeting, dans le plan de charge, etc.
  20. 20. Bonnes pratiques : attention aux « effets de seuil »• Double attention (donc double revue)– Lorsque la recette (la qualification) est q ( q )presque finie– Lors des « quick fix » en prodLors des « quick fix » en prod• La correction d’un bug mineur peut d é bl !introduire une régression bloquante !
  21. 21. Bonnes pratiques : les outilsBonnes pratiques : les outils• Utilisez un outil pour – Packager les changementsg g– Lhistorisation des patchLes compte rendus de revue– Les compte‐rendus de revue.• Utilisez, de préférence, un outil qui sait gérer les patch successifs
  22. 22. Bonnes pratiques : la méthodeBonnes pratiques : la méthodeF i t d’ d• Faire sa propre revue avant d’envoyer un code en revue– Éviter un Review Failed pour des points évidents.p p• Faire une revue rapide avant mise à jour de son espace de travail (Update)Au moins le titre du change la liste des fichiers lauteur– Au moins le titre du change, la liste des fichiers lauteur et le reviewer• Faire toujours une revue de code même si vous ’ èn’avez pas de collègue qui connaisse votre technologie– Prenez le PO, le MOA, un développeur Delphi etPrenez le PO, le MOA, un développeur Delphi et montrez lui votre changement ou, – Au pire, faites votre propre revue le lendemain matin.
  23. 23. Exemple : mozilla orgExemple : mozilla.org• Revue obligatoire pour pouvoir commiter• Intégration du processus dans Bugzilla• Intégration du processus dans Bugzilla• Listes d’examinateurs « accrédités » par area et sous‐modulearea et sous‐module• « Super‐review » nécessaire dans certains cas avec une « Super‐Review Policy » biencas avec une « Super Review Policy » bien définie• « Ui‐review » pour IHM et User« Ui review » pour IHM et User Experience
  24. 24. Exemple : implémentation avec Bugzilla, Mylyn, Eclipse et CVSReview passed> CheckinRevue=> Checkin« Self‐review »Création du patchUpload patchDownload patch
  25. 25. OutilsOutils• C d C ll b t d S tB• Code Collaborator de SmartBear– Intégration avec les gestionnaires de code source et avec les gestionnaires des anomaliesAtl i C ibl• Atlassian Crucible– Intégration avec JIRA et les autres outils Atlassian• Eclipse + Bugzilla + Splinter + Mylyn + patch (CVS, SVN)– Intégration avec l’IDE, possibilité de faire plus que juste regarder le code• Gerrit Code Review– Revue de code et gestion des projets Git en‐ligne• Rietveld– Code Review pour Subversion hébergé sur Google App Engine– Code Review pour Subversion, hébergé sur Google App Engine• Review Board– Interface web sous licence MIT
  26. 26. Questions et réponsesQuestions et réponses
  27. 27. Quelques référencesQuelques références• Mozilla• Mozilla– http://www.mozilla.org/projects/firefox/review.htmlhtt // hi ill /h ki / d i– http://www‐archive.mozilla.org/hacking/code‐review‐faq.htmlhttp://www mozilla org/hacking/reviewers html– http://www.mozilla.org/hacking/reviewers.html• Atlassianhtt // tl i / ft / ibl /l / d– http://www.atlassian.com/software/crucible/learn/codereviewwhitepaper.pdf• SmartBear• SmartBear– http://smartbear.com/docs/BestPracticesForPeerCodeReview pdfeview.pdf
  28. 28. #agilefrancegMerci à nos sponsors :pplatinium gold médiagold

×