• Save
La revue de code : facile !
Upcoming SlideShare
Loading in...5
×
 

La revue de code : facile !

on

  • 1,272 views

Presentation faite à Agile France en 2011 ...

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.

Statistics

Views

Total Views
1,272
Views on SlideShare
1,270
Embed Views
2

Actions

Likes
0
Downloads
0
Comments
0

1 Embed 2

http://www.linkedin.com 2

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

La revue de code : facile ! La revue de code : facile ! Presentation Transcript

  • La revue de code : c’est facile !Lucian PrecupLucian Precupconf.agile‐france.org2011‐05‐27
  • 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)
  • 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 »
  • 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
  • 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
  • La revue de code dans le cycle de développementBesoinsAnalyse techniqueTests unitairesDéveloppementRevue pré‐commitéIntégrationBuild & LivraisonRevue post‐commitTests fonctionnelsDéploiement
  • Qui implémente la revue de code?Qui implémente la revue de code?
  • Le monde Open SourceLe monde Open SourceReviewRefactoringRefactoringModificationspatchpatchSCMCIpatchcheckinRMSuper Reviewcheckin
  • 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 »
  • 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 »
  • Convaincus ? Convaincues ?Convaincus ? Convaincues ?
  • 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
  • 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
  • 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
  • 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
  • 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.
  • 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
  • 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
  • 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.
  • 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 !
  • 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
  • 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.
  • 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
  • Exemple : implémentation avec Bugzilla, Mylyn, Eclipse et CVSReview passed> CheckinRevue=> Checkin« Self‐review »Création du patchUpload patchDownload patch
  • 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
  • Questions et réponsesQuestions et réponses
  • 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
  • #agilefrancegMerci à nos sponsors :pplatinium gold médiagold