Présentation faite à Agile France en 2010 : La revue de code : agile, lean, indispensable ! Alors que l’intégration continue ou les tests unitaires commencent à rentrer dans les "standards", la revue de code est souvent considérée comme optionnelle. Pourtant, les avantages d’une revue de code systématique sont multiples : détection des anomalies très tôt dans le cycle de développement, formation des membres de l’équipe, partage de la connaissance, meilleures solutions techniques par la conjonction des perspectives développeur/examinateur. Cette présentation mettra en évidence les avantages de la revue du code en répondant aux idées reçues comme "la revue du code augmente la durée des développements", ou "nos développeurs sont très bons, ils n’ont pas besoin de revue de code" ou encore "il n’y a personne dans l’équipe qui puisse examiner mon code car je suis le seul à connaître Bash et Ant". En évoquant la revue de code dans l’univers open source, les différents moyens de la mettre en œuvre, ses compléments, les différents outils ; et terminant par une démonstration concrète en utilisant Eclipse, Bugzilla et Mylyn, cette présentation vous convaincra de mettre en place la revue de code systématique dans votre équipe sans attendre. Déroulement : 1/ Avantages 2/ Idées reçues 3/ La revue de code dans l’univers open-source : de la revue du patch par le committeur aux procédures très élaborées comme celles de Mozilla Developer Center. 4/ Moyens de mise en œuvre : à partir de quelle taille des projets, par qui, comment, avant l’intégration ou après, ... 5/ Les compléments de la revue du code : analyse de la qualité du code, scripts pour les normes internes, ... 6/ Comparaison avec d’autres techniques : pair programming, ... 7/ Outils et intégration avec les autres outils de développement ou de gestion du cycle de vie (intégration continue, gestion des anomalies, ...) 8/ Démonstration des avantages sur un exemple concret en utilisant Eclipse, Bugzilla et Mylyn comme outils. 9/ Conclusion : comment la revue de code supporte une démarche agile et lean

1. La revue de code : c’est Agile,
c’est Lean, c’est Indispensable !
Lucian Precup
conf.agile-france.org
2010-05-31

2. Lucian Precup
• Développeur, architecte, chef de projets et
responsable des développements (Java EE,
ETL, BI)
• Consultant en industrialisation des
développements (outils ALM, méthodes de
développement, organisation)

3. Objectif de la présentation
• Mise en place de la revue de code …
• Formelle … et
• Assistée par les outils …

4. Qu’est-ce la revue de code?
• Inspection systématique du code source
• Buts:
– Trouver et corriger des erreurs
– Améliorer la qualité du logiciel
– Améliorer les compétences des développeurs
• Types de revue de code
– Formelle ou informelle, pré ou post commit
– « Over-the-shoulder », par e-mail
– « Pair-programming »

5. Avantages
• Trouver des bugs
• Promouvoir l’apprentissage
• Former
• Promouvoir le partage
• Rendre le code plus maintenable
• Trouver des meilleures solutions techniques

6. La revue du code
augmente la durée
des développements
C’est n’est qu’une
impression. Regardez
la suite.

7. Développement Test Bugfix (et dév) Bugfix
Chez le clientEn interne
Dév (et bugfix) Test Bugfix BugfixRevue
Trouver/corriger bugs en QA 200 x 200€
Trouver/corriger bugs chez
le client
100 x 2000€
Développement 100xxx €
Trouver/corriger bugs à la revue 135 x 60€
Trouver/corriger bugs en QA 110 x 200€
Trouver/corriger bugs chez le
client
55 x 2000€
Développement 90xxx €
La revue de code et le cout des
développements

8. Nos développeurs sont
très bons, ils n’ont pas
besoin de revue de code
La revue de code c’est
la meilleure veille
technologique qui
puisse exister

9. Les Tech Leads n’ont pas
besoin de revue de code
Il ne faut pas oublier le
partage et la formation. Et
puis, personne n’est à l’abri
des bugs 

10. Il n’y a personne dans
l’équipe qui puisse
examiner mon code car
je suis le seul à
connaître Delphi
Le regard d’un
développeur Java sur un
code Delphi peut
donner des idées

11. Mais qui
implémente la
revue de code?
Tous les grands éditeurs
de logiciels ainsi que
beaucoup de projets
open source

12. Le monde Open Source
SCM
CI
RM
Review
Refactoring
Modifications
Super Review
patch
patch
checkin
checkin

13. Processus de mozilla.org
• Revue obligatoire pour pouvoir commiter
• Intégration du processus dans Bugzilla
• Listes d’examinateurs « accrédités » par area
et sous-module
• « Super-review » nécessaire dans certains cas
avec une « Super-Review Policy » bien définie
• « Ui-review » pour IHM et User Experience

14. Implémentations et témoignages
• 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 Data
Federator étaient plus longs mais, en revanche,
ils se stabilisaient très rapidement et les délais
de livraisons étaient très prévisibles »

15. Autres témoignages
• Grand éditeur de logiciel
– Équipe de huit personnes (France et Etats Unis)
– Très productive grâce à la revue asynchrone
pendant la « nuit »
• Equipe de moteur de recherche d’un grand
site d’e-commerce
– La revue de code a réussi à optimiser la mise en
recette
– Très bon retour des développeurs

16. Peut-on
automatiser la
revue?
Des outils trouvent des bugs
et peuvent nous apprendre
beaucoup. Mais il ne faut pas
oublier le partage de la
connaissance

17. Revue automatisée?
• Analyse de la qualité du code
• Scripts pour vérification des normes internes.
Ex:
– Suffisamment de tests unitaires
– Respect des règles d’architecture d’entreprise
• Tests automatiques
Hudson FindBugs Sonar

18. Donc les tests, les outils
d’analyse, l’intégration
continue ne remplacent
pas la revue de code?
Il faut tous les
avoir et ils se
complètent

19. La revue de code comparée à ...
• Un bon département QA
– le coût d’un département QA est plus
important; plus on trouve le bug tard plus il
coûte cher
• Des outils automatiques
– la revue de code ne trouve pas que des
bugs; il y a aussi l’apprentissage, le partage,
la maintenance
• L’intégration continue
– Même si les problèmes sont détectés très
tôt, la revue de code permet de les trouver
encore plus tôt

20. Et le « pair
programming » ?
Bonne remarque !

21. Quid du 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é dans le code
• Trop coûteux à implémenter
• Présence physique au même endroit

22. Les outils qui m’aident à
bien implémenter la revue
coûtent cher
Pas forcément

23. Outils et intégration
• Code Collaborator de SmartBear
– Intégration avec les gestionnaires de code source
et avec les gestionnaires des anomalies
• Atlassian Crucible
– Intégration avec JIRA et les autres outils Atlassian
• Eclipse + Bugzilla + Mylyn + patch (CVS, SVN)
– Intégration avec l’IDE, possibilité de faire plus que
juste regarder le code

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

25. Mise en œuvre
• Taille des projets?
• Par qui, comment?
• Avant l’intégration ou après?
• Regarder juste le code ou faire plus?
• Quel type de revue de code est le mieux
adapté à ma situation?

26. Et l’agilité dans tout ça ?
La revue de code fait
partie d’une démarche
agile, lean et industrielle

27. La revue de code c’est agile!
• Le manifeste agile (extrait)
– Les individus et les interactions à l’opposé des processus et
outils
– Logiciels qui fonctionnent à l’opposé de documentation
exhaustive
• Les principes agiles (extrait)
– Satisfaire le client est le plus important – livrer un logiciel qui
fonctionne bien, le plus tôt et le plus souvent possible
– L’avancement est mesuré d’abord à travers le logiciel qui
fonctionne
– Les équipes s’auto-organisent et les individus sont très motivés
– Les discussions face à face sont privilégiées pour la
communication
– Des rétrospectives et ajustements sont faits de façon régulière

28. La revue de code c’est Lean!
• Approche Lean
– améliorer la qualité et les délais
– réduire les coûts en tirant le meilleur parti des ressources
humaines et matérielles, et en évitant toute forme de gaspillage
• Principes (extrait)
– Éliminer les gaspillages (trop de fonctionnalités, travail
partiellement fait, réapprentissage, transmission de
l’information, commutation entre tâches, retards, défauts)
– Favoriser la connaissance
– Construire la qualité intrinsèque
– Livrer rapidement
– Respecter les personnes
– Optimiser le système dans son ensemble

29. La revue de code - conclusion
• Mettez-la en place tout de suite
• Favoriser la revue formelle
• Appuyez-vous sur des outils

30. Questions et réponses

31. Quelques références
• Mozilla
– http://www.mozilla.org/projects/firefox/review.html
– http://www-archive.mozilla.org/hacking/code-review-
faq.html
– http://www.mozilla.org/hacking/reviewers.html
• Atlassian
– http://www.atlassian.com/software/crucible/learn/coderevi
ewwhitepaper.pdf
• SmartBear
– http://smartbear.com/docs/BestPracticesForPeerCodeRevie
w.pdf
• http://LucianPrecup.com
– Livre blanc bientôt disponible