La revue de code est un processus systématique visant à améliorer la qualité du code et la communication au sein des équipes de développement. Elle peut prendre différentes formes et offre plusieurs avantages, notamment la réduction des bugs et une meilleure formation des membres de l'équipe. Cependant, des pièges et défis peuvent survenir lors de sa mise en œuvre, nécessitant l'adoption de bonnes pratiques pour un processus efficace.

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

6. 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

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

24. Exemple : implémentation avec
Bugzilla, Mylyn, Eclipse et CVS
Review passed
> Checkin
Revue
=> Checkin« Self‐review »
Création du patch
Upload patch
Download patch

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

26. Questions et réponsesQuestions et réponses

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