La présentation aborde l'importance de la revue de code comme méthode essentielle pour améliorer la qualité des logiciels, favoriser l'apprentissage des développeurs et réduire les coûts liés aux bugs. Elle distingue différents types de revue de code, souligne les avantages d'une intégration formelle et assister par des outils, et établit un lien entre la revue de code et les méthodologies agiles et lean. Enfin, elle recommande la mise en place immédiate de la revue de code en s'appuyant sur les meilleures pratiques et outils disponibles.

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