SlideShare une entreprise Scribd logo
1  sur  28
La revue de code : c’est facile !
Lucian PrecupLucian Precup
conf.agile‐france.org
2011‐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 »
AvantagesAvantages
Di t• Directs: 
– Meilleure qualité du code
Moins 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 p
dé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éveloppement
Besoins
Analyse technique
Tests unitaires
Développement
Revue pré‐commit
éIntégration
Build & Livraison
Revue post‐commit
Tests fonctionnels
Déploiement
Qui implémente la revue de code?Qui implémente la revue de code?
Le monde Open SourceLe monde Open Source
Review
RefactoringRefactoring
Modifications
patch
patch
SCM
CI
patch
checkin
RM
Super Review
checkin
Implémentations et témoignagesImplémentations et témoignages
f 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émoignages
G 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 I've 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 œuvre
L 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éthode
F 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 revues
l ’ f i• Interrompre quelqu’un pour  faire une 
revue
S’ 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 Failed
A 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 n'a rien à voir avec 
le code qui est en revue.
Piège numéro 5: les outilsPiège numéro 5: les outils
l 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 Programming
i 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 processus
d 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âche
d 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
– L'historisation des patch
Les 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éthode
F 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 l'auteur– Au moins le titre du change, la liste des fichiers l'auteur 
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 CVS
Review passed
> Checkin
Revue
=> Checkin« Self‐review »
Création du patch
Upload patch
Download 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 anomalies
Atl 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.html
htt // hi ill /h ki / d i– http://www‐archive.mozilla.org/hacking/code‐review‐
faq.html
http://www mozilla org/hacking/reviewers html– http://www.mozilla.org/hacking/reviewers.html
• Atlassian
htt // tl i / ft / ibl /l / d– http://www.atlassian.com/software/crucible/learn/cod
ereviewwhitepaper.pdf
• SmartBear• SmartBear
– http://smartbear.com/docs/BestPracticesForPeerCodeR
eview pdfeview.pdf
#agilefranceg
Merci à nos sponsors :p
platinium gold médiagold

Contenu connexe

Tendances

Static Code Analysis
Static Code AnalysisStatic Code Analysis
Static Code AnalysisAnnyce Davis
 
CNIT 129S Ch 4: Mapping the Application
CNIT 129S Ch 4: Mapping the ApplicationCNIT 129S Ch 4: Mapping the Application
CNIT 129S Ch 4: Mapping the ApplicationSam Bowne
 
Single Responsibility Principle
Single Responsibility PrincipleSingle Responsibility Principle
Single Responsibility PrincipleEyal Golan
 
Introdução a testes de software utilizando selenium
Introdução a testes de software utilizando seleniumIntrodução a testes de software utilizando selenium
Introdução a testes de software utilizando seleniumSandy Maciel
 
Prueba De Aplicaciones Web con Selenium 2 y WebDriver
Prueba De Aplicaciones Web con Selenium 2 y WebDriverPrueba De Aplicaciones Web con Selenium 2 y WebDriver
Prueba De Aplicaciones Web con Selenium 2 y WebDriverDavid Gómez García
 
Bdd com cucumber + java + selenium
Bdd com cucumber + java + seleniumBdd com cucumber + java + selenium
Bdd com cucumber + java + seleniumSandy Maciel
 
Code review guidelines
Code review guidelinesCode review guidelines
Code review guidelinesLalit Kale
 
MVC, MVVM, ReactorKit, VIPER를 거쳐 RIB 정착기
MVC, MVVM, ReactorKit, VIPER를 거쳐 RIB 정착기MVC, MVVM, ReactorKit, VIPER를 거쳐 RIB 정착기
MVC, MVVM, ReactorKit, VIPER를 거쳐 RIB 정착기정민 안
 
Spring IO 2023 - Dynamic OpenAPIs with Spring Cloud Gateway
Spring IO 2023 - Dynamic OpenAPIs with Spring Cloud GatewaySpring IO 2023 - Dynamic OpenAPIs with Spring Cloud Gateway
Spring IO 2023 - Dynamic OpenAPIs with Spring Cloud GatewayIván López Martín
 
Asynchronous javascript
 Asynchronous javascript Asynchronous javascript
Asynchronous javascriptEman Mohamed
 
Server-side JS with NodeJS
Server-side JS with NodeJSServer-side JS with NodeJS
Server-side JS with NodeJSLilia Sfaxi
 
Clean code presentation
Clean code presentationClean code presentation
Clean code presentationBhavin Gandhi
 
SonarQube - Should I Stay or Should I Go ?
SonarQube - Should I Stay or Should I Go ? SonarQube - Should I Stay or Should I Go ?
SonarQube - Should I Stay or Should I Go ? Geeks Anonymes
 
Code Review Best Practices
Code Review Best PracticesCode Review Best Practices
Code Review Best PracticesTrisha Gee
 
Practical Malware Analysis Ch 14: Malware-Focused Network Signatures
Practical Malware Analysis Ch 14: Malware-Focused Network SignaturesPractical Malware Analysis Ch 14: Malware-Focused Network Signatures
Practical Malware Analysis Ch 14: Malware-Focused Network SignaturesSam Bowne
 

Tendances (20)

Static Code Analysis
Static Code AnalysisStatic Code Analysis
Static Code Analysis
 
CNIT 129S Ch 4: Mapping the Application
CNIT 129S Ch 4: Mapping the ApplicationCNIT 129S Ch 4: Mapping the Application
CNIT 129S Ch 4: Mapping the Application
 
Single Responsibility Principle
Single Responsibility PrincipleSingle Responsibility Principle
Single Responsibility Principle
 
Introdução a testes de software utilizando selenium
Introdução a testes de software utilizando seleniumIntrodução a testes de software utilizando selenium
Introdução a testes de software utilizando selenium
 
Prueba De Aplicaciones Web con Selenium 2 y WebDriver
Prueba De Aplicaciones Web con Selenium 2 y WebDriverPrueba De Aplicaciones Web con Selenium 2 y WebDriver
Prueba De Aplicaciones Web con Selenium 2 y WebDriver
 
Code Quality
Code QualityCode Quality
Code Quality
 
Bdd com cucumber + java + selenium
Bdd com cucumber + java + seleniumBdd com cucumber + java + selenium
Bdd com cucumber + java + selenium
 
Flask
FlaskFlask
Flask
 
Code review guidelines
Code review guidelinesCode review guidelines
Code review guidelines
 
ReST API Security
ReST API SecurityReST API Security
ReST API Security
 
MVC, MVVM, ReactorKit, VIPER를 거쳐 RIB 정착기
MVC, MVVM, ReactorKit, VIPER를 거쳐 RIB 정착기MVC, MVVM, ReactorKit, VIPER를 거쳐 RIB 정착기
MVC, MVVM, ReactorKit, VIPER를 거쳐 RIB 정착기
 
Spring IO 2023 - Dynamic OpenAPIs with Spring Cloud Gateway
Spring IO 2023 - Dynamic OpenAPIs with Spring Cloud GatewaySpring IO 2023 - Dynamic OpenAPIs with Spring Cloud Gateway
Spring IO 2023 - Dynamic OpenAPIs with Spring Cloud Gateway
 
Asynchronous javascript
 Asynchronous javascript Asynchronous javascript
Asynchronous javascript
 
Server-side JS with NodeJS
Server-side JS with NodeJSServer-side JS with NodeJS
Server-side JS with NodeJS
 
Clean code presentation
Clean code presentationClean code presentation
Clean code presentation
 
User Stories Refactoring
User Stories RefactoringUser Stories Refactoring
User Stories Refactoring
 
SonarQube - Should I Stay or Should I Go ?
SonarQube - Should I Stay or Should I Go ? SonarQube - Should I Stay or Should I Go ?
SonarQube - Should I Stay or Should I Go ?
 
Code Review Best Practices
Code Review Best PracticesCode Review Best Practices
Code Review Best Practices
 
Selenium IDE
Selenium IDESelenium IDE
Selenium IDE
 
Practical Malware Analysis Ch 14: Malware-Focused Network Signatures
Practical Malware Analysis Ch 14: Malware-Focused Network SignaturesPractical Malware Analysis Ch 14: Malware-Focused Network Signatures
Practical Malware Analysis Ch 14: Malware-Focused Network Signatures
 

En vedette

La revue de code : agile, lean, indispensable !
La revue de code : agile, lean, indispensable !La revue de code : agile, lean, indispensable !
La revue de code : agile, lean, indispensable !Lucian Precup
 
Ratez vos revue de code en 5 lecons devoxx fr 2016
Ratez vos revue de code en 5 lecons   devoxx fr 2016Ratez vos revue de code en 5 lecons   devoxx fr 2016
Ratez vos revue de code en 5 lecons devoxx fr 2016Michel Domenjoud
 
Jean-Claude Katende - Groupe de travail sur la protection
Jean-Claude Katende - Groupe de travail sur la protectionJean-Claude Katende - Groupe de travail sur la protection
Jean-Claude Katende - Groupe de travail sur la protectionPublish What You Pay
 
Presentacion share point 2010
Presentacion share point 2010Presentacion share point 2010
Presentacion share point 2010MICTT Palma
 
Clase del 6 de octubre de 2011
Clase del 6 de octubre de 2011Clase del 6 de octubre de 2011
Clase del 6 de octubre de 2011JF Chapa
 
Biblitecología en colombia presentación
Biblitecología en colombia presentaciónBiblitecología en colombia presentación
Biblitecología en colombia presentaciónsolanyi27
 
Cambios en el embarazo
Cambios en el embarazoCambios en el embarazo
Cambios en el embarazo07021982
 
Le temps des élus - Idate
Le temps des élus - IdateLe temps des élus - Idate
Le temps des élus - IdateCap'Com
 
Bloque cierre pacie integración
Bloque cierre pacie integraciónBloque cierre pacie integración
Bloque cierre pacie integraciónprofesorapetra
 
Programme Cap'Com 2002
Programme Cap'Com 2002Programme Cap'Com 2002
Programme Cap'Com 2002Cap'Com
 
Le TDE : de quoi parle-t-on ?
Le TDE : de quoi parle-t-on ?Le TDE : de quoi parle-t-on ?
Le TDE : de quoi parle-t-on ?Cap'Com
 
Bonnes pratiques du e-commerce: cas Compufirst
Bonnes pratiques du e-commerce: cas CompufirstBonnes pratiques du e-commerce: cas Compufirst
Bonnes pratiques du e-commerce: cas CompufirstLudovic Charbonnel
 
Tableau Comparaison art.73 art. 74
Tableau Comparaison art.73  art. 74Tableau Comparaison art.73  art. 74
Tableau Comparaison art.73 art. 74lafontaine
 
Note relative à l'élaboration des dossiers collectifs
Note relative à l'élaboration des dossiers collectifsNote relative à l'élaboration des dossiers collectifs
Note relative à l'élaboration des dossiers collectifsMarie Biscarat
 
La veille de red guy du 16.07.14 parler aux étudiants
La veille de red guy du 16.07.14   parler aux étudiantsLa veille de red guy du 16.07.14   parler aux étudiants
La veille de red guy du 16.07.14 parler aux étudiantsRed Guy
 

En vedette (20)

La revue de code : agile, lean, indispensable !
La revue de code : agile, lean, indispensable !La revue de code : agile, lean, indispensable !
La revue de code : agile, lean, indispensable !
 
Ratez vos revue de code en 5 lecons devoxx fr 2016
Ratez vos revue de code en 5 lecons   devoxx fr 2016Ratez vos revue de code en 5 lecons   devoxx fr 2016
Ratez vos revue de code en 5 lecons devoxx fr 2016
 
Jean-Claude Katende - Groupe de travail sur la protection
Jean-Claude Katende - Groupe de travail sur la protectionJean-Claude Katende - Groupe de travail sur la protection
Jean-Claude Katende - Groupe de travail sur la protection
 
Presentacion share point 2010
Presentacion share point 2010Presentacion share point 2010
Presentacion share point 2010
 
Clase del 6 de octubre de 2011
Clase del 6 de octubre de 2011Clase del 6 de octubre de 2011
Clase del 6 de octubre de 2011
 
Biblitecología en colombia presentación
Biblitecología en colombia presentaciónBiblitecología en colombia presentación
Biblitecología en colombia presentación
 
Cambios en el embarazo
Cambios en el embarazoCambios en el embarazo
Cambios en el embarazo
 
Le temps des élus - Idate
Le temps des élus - IdateLe temps des élus - Idate
Le temps des élus - Idate
 
Foto 2
Foto 2Foto 2
Foto 2
 
Bloque cierre pacie integración
Bloque cierre pacie integraciónBloque cierre pacie integración
Bloque cierre pacie integración
 
Programme Cap'Com 2002
Programme Cap'Com 2002Programme Cap'Com 2002
Programme Cap'Com 2002
 
Projet ca..
Projet ca..Projet ca..
Projet ca..
 
Le TDE : de quoi parle-t-on ?
Le TDE : de quoi parle-t-on ?Le TDE : de quoi parle-t-on ?
Le TDE : de quoi parle-t-on ?
 
Bonnes pratiques du e-commerce: cas Compufirst
Bonnes pratiques du e-commerce: cas CompufirstBonnes pratiques du e-commerce: cas Compufirst
Bonnes pratiques du e-commerce: cas Compufirst
 
Principes de mesure de l’immatériel
Principes de mesure de l’immatérielPrincipes de mesure de l’immatériel
Principes de mesure de l’immatériel
 
Mon histoire
Mon histoireMon histoire
Mon histoire
 
Tableau Comparaison art.73 art. 74
Tableau Comparaison art.73  art. 74Tableau Comparaison art.73  art. 74
Tableau Comparaison art.73 art. 74
 
Note relative à l'élaboration des dossiers collectifs
Note relative à l'élaboration des dossiers collectifsNote relative à l'élaboration des dossiers collectifs
Note relative à l'élaboration des dossiers collectifs
 
T&d
T&dT&d
T&d
 
La veille de red guy du 16.07.14 parler aux étudiants
La veille de red guy du 16.07.14   parler aux étudiantsLa veille de red guy du 16.07.14   parler aux étudiants
La veille de red guy du 16.07.14 parler aux étudiants
 

Similaire à La revue de code : facile !

La relecture de code : avant tout des pratiques
La relecture de code : avant tout des pratiquesLa relecture de code : avant tout des pratiques
La relecture de code : avant tout des pratiquesEric SIBER
 
Jenkins - Les jeudis de la découverte
Jenkins - Les jeudis de la découverteJenkins - Les jeudis de la découverte
Jenkins - Les jeudis de la découverteStephane Couzinier
 
Le rôle du testeur et le Blackbox testing
Le rôle du testeur et le Blackbox testingLe rôle du testeur et le Blackbox testing
Le rôle du testeur et le Blackbox testingGeeks Anonymes
 
Agile tour 2015 alliés contre les défauts
Agile tour 2015   alliés contre les défautsAgile tour 2015   alliés contre les défauts
Agile tour 2015 alliés contre les défautsJulien Jakubowski
 
Agile tour Lille 2015 allies ensemble contre les defauts
Agile tour Lille 2015 allies ensemble contre les defautsAgile tour Lille 2015 allies ensemble contre les defauts
Agile tour Lille 2015 allies ensemble contre les defautsAntoine Blk
 
Deux ans de développement Agile, erreurs et succès
Deux ans de développement Agile, erreurs et succèsDeux ans de développement Agile, erreurs et succès
Deux ans de développement Agile, erreurs et succèsAgile Tour 2009 Québec
 
20131024 qualité de code et sonar - mug lyon
20131024   qualité de code et sonar - mug lyon20131024   qualité de code et sonar - mug lyon
20131024 qualité de code et sonar - mug lyonClement Bouillier
 
Tester du legacy code, mission impossible ?
Tester du legacy code, mission impossible ?Tester du legacy code, mission impossible ?
Tester du legacy code, mission impossible ?CGI Québec Formation
 
Mix-IT 2013 - Agilistes : n'oubliez pas la technique - mix-it 2013
Mix-IT 2013 - Agilistes : n'oubliez pas la technique - mix-it 2013Mix-IT 2013 - Agilistes : n'oubliez pas la technique - mix-it 2013
Mix-IT 2013 - Agilistes : n'oubliez pas la technique - mix-it 2013Xavier NOPRE
 
Altran soirée du test logiciel - assez des c 05-10-17
Altran   soirée du test logiciel - assez des c 05-10-17Altran   soirée du test logiciel - assez des c 05-10-17
Altran soirée du test logiciel - assez des c 05-10-17Marc Hage Chahine
 
Soirée du Test Logiciel - Intégration, livraison et déploiement continu - A. ...
Soirée du Test Logiciel - Intégration, livraison et déploiement continu - A. ...Soirée du Test Logiciel - Intégration, livraison et déploiement continu - A. ...
Soirée du Test Logiciel - Intégration, livraison et déploiement continu - A. ...TelecomValley
 
Agile Tour 2010 - Mise en place d'un projet agile
Agile Tour 2010 - Mise en place d'un projet agileAgile Tour 2010 - Mise en place d'un projet agile
Agile Tour 2010 - Mise en place d'un projet agileLaurent Deséchalliers
 
AT2010 Mise place d'un projet Agile
AT2010 Mise place d'un projet AgileAT2010 Mise place d'un projet Agile
AT2010 Mise place d'un projet AgileNormandy JUG
 
Mockito - Design + tests par Brice Duteil
Mockito - Design + tests par Brice DuteilMockito - Design + tests par Brice Duteil
Mockito - Design + tests par Brice DuteilNormandy JUG
 
20110519 cara tests_agiles_grenoble_all
20110519 cara tests_agiles_grenoble_all20110519 cara tests_agiles_grenoble_all
20110519 cara tests_agiles_grenoble_allCARA_Lyon
 
Développement en méthode agile
Développement en méthode agileDéveloppement en méthode agile
Développement en méthode agilelaurent bristiel
 
Introduction aux spécifications exécutables (dit aussi atdd, bdd)
Introduction aux spécifications exécutables (dit aussi atdd, bdd)Introduction aux spécifications exécutables (dit aussi atdd, bdd)
Introduction aux spécifications exécutables (dit aussi atdd, bdd)Jean-Pierre Lambert
 
PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...
PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...
PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...Cyrille Grandval
 

Similaire à La revue de code : facile ! (20)

La relecture de code : avant tout des pratiques
La relecture de code : avant tout des pratiquesLa relecture de code : avant tout des pratiques
La relecture de code : avant tout des pratiques
 
Jenkins - Les jeudis de la découverte
Jenkins - Les jeudis de la découverteJenkins - Les jeudis de la découverte
Jenkins - Les jeudis de la découverte
 
Le rôle du testeur et le Blackbox testing
Le rôle du testeur et le Blackbox testingLe rôle du testeur et le Blackbox testing
Le rôle du testeur et le Blackbox testing
 
Agile tour 2015 alliés contre les défauts
Agile tour 2015   alliés contre les défautsAgile tour 2015   alliés contre les défauts
Agile tour 2015 alliés contre les défauts
 
Agile tour Lille 2015 allies ensemble contre les defauts
Agile tour Lille 2015 allies ensemble contre les defautsAgile tour Lille 2015 allies ensemble contre les defauts
Agile tour Lille 2015 allies ensemble contre les defauts
 
Deux ans de développement Agile, erreurs et succès
Deux ans de développement Agile, erreurs et succèsDeux ans de développement Agile, erreurs et succès
Deux ans de développement Agile, erreurs et succès
 
C'est quoi un bon dev ?
C'est quoi un bon dev ?C'est quoi un bon dev ?
C'est quoi un bon dev ?
 
20131024 qualité de code et sonar - mug lyon
20131024   qualité de code et sonar - mug lyon20131024   qualité de code et sonar - mug lyon
20131024 qualité de code et sonar - mug lyon
 
Tester du legacy code, mission impossible ?
Tester du legacy code, mission impossible ?Tester du legacy code, mission impossible ?
Tester du legacy code, mission impossible ?
 
Mix-IT 2013 - Agilistes : n'oubliez pas la technique - mix-it 2013
Mix-IT 2013 - Agilistes : n'oubliez pas la technique - mix-it 2013Mix-IT 2013 - Agilistes : n'oubliez pas la technique - mix-it 2013
Mix-IT 2013 - Agilistes : n'oubliez pas la technique - mix-it 2013
 
Altran soirée du test logiciel - assez des c 05-10-17
Altran   soirée du test logiciel - assez des c 05-10-17Altran   soirée du test logiciel - assez des c 05-10-17
Altran soirée du test logiciel - assez des c 05-10-17
 
Soirée du Test Logiciel - Intégration, livraison et déploiement continu - A. ...
Soirée du Test Logiciel - Intégration, livraison et déploiement continu - A. ...Soirée du Test Logiciel - Intégration, livraison et déploiement continu - A. ...
Soirée du Test Logiciel - Intégration, livraison et déploiement continu - A. ...
 
Agile Tour 2010 - Mise en place d'un projet agile
Agile Tour 2010 - Mise en place d'un projet agileAgile Tour 2010 - Mise en place d'un projet agile
Agile Tour 2010 - Mise en place d'un projet agile
 
AT2010 Mise place d'un projet Agile
AT2010 Mise place d'un projet AgileAT2010 Mise place d'un projet Agile
AT2010 Mise place d'un projet Agile
 
Mockito - Design + tests par Brice Duteil
Mockito - Design + tests par Brice DuteilMockito - Design + tests par Brice Duteil
Mockito - Design + tests par Brice Duteil
 
20110519 cara tests_agiles_grenoble_all
20110519 cara tests_agiles_grenoble_all20110519 cara tests_agiles_grenoble_all
20110519 cara tests_agiles_grenoble_all
 
Développement en méthode agile
Développement en méthode agileDéveloppement en méthode agile
Développement en méthode agile
 
Lunch learn 5 sep2013
Lunch learn 5 sep2013Lunch learn 5 sep2013
Lunch learn 5 sep2013
 
Introduction aux spécifications exécutables (dit aussi atdd, bdd)
Introduction aux spécifications exécutables (dit aussi atdd, bdd)Introduction aux spécifications exécutables (dit aussi atdd, bdd)
Introduction aux spécifications exécutables (dit aussi atdd, bdd)
 
PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...
PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...
PHPTour Lyon 2014 - Conférence - Tests unitaires Je veux mes 80% de couvertur...
 

Plus de Lucian Precup

Enrich data and rewrite queries with the Elasticsearch percolator
Enrich data and rewrite queries with the Elasticsearch percolatorEnrich data and rewrite queries with the Elasticsearch percolator
Enrich data and rewrite queries with the Elasticsearch percolatorLucian Precup
 
Joins in a distributed world Distributed Matters Barcelona 2015
Joins in a distributed world Distributed Matters Barcelona 2015Joins in a distributed world Distributed Matters Barcelona 2015
Joins in a distributed world Distributed Matters Barcelona 2015Lucian Precup
 
Search and nosql for information management @nosqlmatters Cologne
Search and nosql for information management @nosqlmatters CologneSearch and nosql for information management @nosqlmatters Cologne
Search and nosql for information management @nosqlmatters CologneLucian Precup
 
Back to the future : SQL 92 for Elasticsearch ? @nosqlmatters Dublin 2014
Back to the future : SQL 92 for Elasticsearch ? @nosqlmatters Dublin 2014Back to the future : SQL 92 for Elasticsearch ? @nosqlmatters Dublin 2014
Back to the future : SQL 92 for Elasticsearch ? @nosqlmatters Dublin 2014Lucian Precup
 
Back to the future : SQL 92 for Elasticsearch @nosqlmatters Paris
Back to the future : SQL 92 for Elasticsearch @nosqlmatters ParisBack to the future : SQL 92 for Elasticsearch @nosqlmatters Paris
Back to the future : SQL 92 for Elasticsearch @nosqlmatters ParisLucian Precup
 
Search, nosql et bigdata avec les moteurs de recherche
Search, nosql et bigdata avec les moteurs de rechercheSearch, nosql et bigdata avec les moteurs de recherche
Search, nosql et bigdata avec les moteurs de rechercheLucian Precup
 
ALM et Agilite : la convergence
ALM et Agilite : la convergenceALM et Agilite : la convergence
ALM et Agilite : la convergenceLucian Precup
 
Moteurs de recherche et Lucene at LorraineJUG
Moteurs de recherche et Lucene at LorraineJUGMoteurs de recherche et Lucene at LorraineJUG
Moteurs de recherche et Lucene at LorraineJUGLucian Precup
 
Solr and Elasticsearch in Action (at Breizhcamp)
Solr and Elasticsearch in Action (at Breizhcamp)Solr and Elasticsearch in Action (at Breizhcamp)
Solr and Elasticsearch in Action (at Breizhcamp)Lucian Precup
 

Plus de Lucian Precup (9)

Enrich data and rewrite queries with the Elasticsearch percolator
Enrich data and rewrite queries with the Elasticsearch percolatorEnrich data and rewrite queries with the Elasticsearch percolator
Enrich data and rewrite queries with the Elasticsearch percolator
 
Joins in a distributed world Distributed Matters Barcelona 2015
Joins in a distributed world Distributed Matters Barcelona 2015Joins in a distributed world Distributed Matters Barcelona 2015
Joins in a distributed world Distributed Matters Barcelona 2015
 
Search and nosql for information management @nosqlmatters Cologne
Search and nosql for information management @nosqlmatters CologneSearch and nosql for information management @nosqlmatters Cologne
Search and nosql for information management @nosqlmatters Cologne
 
Back to the future : SQL 92 for Elasticsearch ? @nosqlmatters Dublin 2014
Back to the future : SQL 92 for Elasticsearch ? @nosqlmatters Dublin 2014Back to the future : SQL 92 for Elasticsearch ? @nosqlmatters Dublin 2014
Back to the future : SQL 92 for Elasticsearch ? @nosqlmatters Dublin 2014
 
Back to the future : SQL 92 for Elasticsearch @nosqlmatters Paris
Back to the future : SQL 92 for Elasticsearch @nosqlmatters ParisBack to the future : SQL 92 for Elasticsearch @nosqlmatters Paris
Back to the future : SQL 92 for Elasticsearch @nosqlmatters Paris
 
Search, nosql et bigdata avec les moteurs de recherche
Search, nosql et bigdata avec les moteurs de rechercheSearch, nosql et bigdata avec les moteurs de recherche
Search, nosql et bigdata avec les moteurs de recherche
 
ALM et Agilite : la convergence
ALM et Agilite : la convergenceALM et Agilite : la convergence
ALM et Agilite : la convergence
 
Moteurs de recherche et Lucene at LorraineJUG
Moteurs de recherche et Lucene at LorraineJUGMoteurs de recherche et Lucene at LorraineJUG
Moteurs de recherche et Lucene at LorraineJUG
 
Solr and Elasticsearch in Action (at Breizhcamp)
Solr and Elasticsearch in Action (at Breizhcamp)Solr and Elasticsearch in Action (at Breizhcamp)
Solr and Elasticsearch in Action (at Breizhcamp)
 

La revue de code : facile !

  • 1. La revue de code : c’est facile ! Lucian PrecupLucian Precup conf.agile‐france.org 2011‐05‐27
  • 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. 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. AvantagesAvantages Di t• Directs:  – Meilleure qualité du code Moins 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. Objectif de la présentationObjectif de la présentation • Mise en place de la revue de code comme  étape incontournable du processus de p p développement – Les bonnes pratiques– Les bonnes pratiques – Les pièges à éviter – Exemples – Retours d’expérience
  • 7. Qui implémente la revue de code?Qui implémente la revue de code?
  • 8. Le monde Open SourceLe monde Open Source Review RefactoringRefactoring Modifications patch patch SCM CI patch checkin RM Super Review checkin
  • 9. Implémentations et témoignagesImplémentations et témoignages f 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. Autres témoignagesAutres témoignages G 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 I've 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. Convaincus ? Convaincues ?Convaincus ? Convaincues ?
  • 12. Difficultés à la mise en œuvreDifficultés à la mise en œuvre L 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. Piège numéro 1 : mauvaise méthodePiège numéro 1 : mauvaise méthode F 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 revues l ’ f i• Interrompre quelqu’un pour  faire une  revue S’ 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. 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. Piège numéro 3: le "Review Failed"Piège numéro 3: le  Review Failed A 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. 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 n'a rien à voir avec  le code qui est en revue.
  • 17. Piège numéro 5: les outilsPiège numéro 5: les outils l 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. Piège numéro 6 :  Miser tout sur le Pair Programming i 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. Bonnes pratiques : le processusBonnes pratiques : le processus d 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âche d d l l d h– en stand‐up meeting, dans le plan de charge, etc.
  • 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. Bonnes pratiques : les outilsBonnes pratiques : les outils • Utilisez un outil pour  – Packager les changementsg g – L'historisation des patch Les compte rendus de revue– Les compte‐rendus de revue. • Utilisez, de préférence, un outil qui sait gérer  les patch successifs
  • 22. Bonnes pratiques : la méthodeBonnes pratiques : la méthode F 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 l'auteur– Au moins le titre du change, la liste des fichiers l'auteur  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. 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
  • 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 anomalies Atl 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
  • 27. Quelques référencesQuelques références • Mozilla• Mozilla – http://www.mozilla.org/projects/firefox/review.html htt // hi ill /h ki / d i– http://www‐archive.mozilla.org/hacking/code‐review‐ faq.html http://www mozilla org/hacking/reviewers html– http://www.mozilla.org/hacking/reviewers.html • Atlassian htt // tl i / ft / ibl /l / d– http://www.atlassian.com/software/crucible/learn/cod ereviewwhitepaper.pdf • SmartBear• SmartBear – http://smartbear.com/docs/BestPracticesForPeerCodeR eview pdfeview.pdf
  • 28. #agilefranceg Merci à nos sponsors :p platinium gold médiagold