Retour d'experience sur la revue de code chez Fabernovel Technologies.

1. Code Review
La revue de code chez Fabernovel Technologies
Lyon, le 17 Mai 2018

2. 2//
La revue de code est
chronophage
Pour quels bénéfices ?

3. 3//
En production logiciel, des bugs surviennent
forcément
Quand ?
● Développement
● Tests, Q&A
● Post Déploiement
→ Plus on attend, plus le coût est important

4. 4//
Autres bénéfices :
● qualité du code
● communication entre
devs
● entraîner les juniors
Code review
Une revue, même rapide, permet de trouver beaucoup
de bug

5. 5//
Et indirectement :
● durée des cycles de
développement/test
● l’impact sur le support technique
● la production de code plus
maintenable
● formaliser des critères de qualité

6. 6//
Quelle type de review ?
● simple relecture
● ...
● étude complète en
groupe
Code Review
Choix de la review

7. 7//
Gerrit
Notre outil
● Surcouche de git
● interface web
● visualisation de diff
● système de notation
● intégration de la CI

8. 8//
Code review
Ce que nous vérifions
Le coding style :
● Strict → très homogène
● Validé par la CI (Swiftlint/Lint avec
Sonar)

9. 9//
Code review
Ce que nous vérifions
Propreté du code :
● Critères SOLID
● Duplication ?
● gestion des erreurs ?
● Sécurité de l’API
→ Saisir les opportunités de nettoyage

10. 10//
Code review
Ce que nous vérifions
Compréhensibilité
● Nommage
● fonction de petite taille
● le code s’auto-documente
● commentaires précis
→ Le développeur est son premier relecteur

11. 11//
Code review
Ce que nous vérifions
Vue macro :
● Vue d’ensemble
● Fonctionnement
● élégance
→ Permet d’apprendre, et trouver des bugs

12. 12//
Code review
Ce que nous vérifions
Tester et challenger
● Tester le fonctionnement
● Réfléchir à sa propre
implémentation

13. 13//
Prendre son temps
Autant ne pas faire, que bâcler

14. 14//
Code review
Ce que nous vérifions
Faut il tout relire ?
● cf. point précédent
→ Attention aux inattentions

15. 15//
Code review
Bonne ambiance nécessaire
Attention aux égos
● Expliquer, soulever des questions,
plutôt que critiquer
● Ne pas prendre la critique
personnellement
● Ouvrir à la discussion
→ Laisser des commentaires positifs !

16. 16//
Code review
Bonne ambiance nécessaire
Prendre soin du relecteur
● Il dépile les commits
● Éviter les changements
d'implémentation
→ Garder un historique propre

17. 17//
Code review
Réduire la “zone grise”
● Sujets subjectifs à avis divergents
● Rester conciliant et expliquer
clairement
● En cas de désaccord, discussion
collégiale, puis choix de la régle
→ C’est le point le plus compliqué de la review
Bonne ambiance nécessaire

18. 18//
Code review
Il est autorisé de ne pas être sur
● Tout le monde peut relire
● Utiliser la note +1, qui demande un
autre avis
Bonne ambiance nécessaire

19. 19//
Code review
● Pas si chronophage
● Améliore la communication
● et la qualité du code
→ C’est devenu une étape obligatoire sur chaque
commit
Finalement

20. Merci.
20//
Benjamin LAVIALLE
Senior iOS Developer
benjamin.lavialle@applidium.com