Comment améliorer ses codes reviews
La code review c’est le moment où on montre le résultat de son travail.
Le code est évalué, et on peut se sentir évalué.
Mais être un bon développeur, c’est aussi être un bon relecteur !
Voici donc une liste des best practices pour maximiser l’efficacité de la code review et la rendre positive pour toute l’équipe.
Selon une étude menée par SmartBear en 2018, 24% des développeurs considèrent la code review comme le premier levier d’amélioration de la qualité du code, devant les tests unitaires (20%) et les tests d’intégration (11%).
Paradoxalement seul 43% des développeurs interrogés se considèrent satisfaits par leur processus de code review.
Il est donc important pour une équipe de pouvoir formaliser ce processus de manière à maximiser la satisfaction des développeurs tout en maintenant une qualité de code élevée.
Voici donc un résumé des best practices à mettre en place quand on review, et ce qui est fait au sein de Captain Contrat pour permettre de les réaliser.
Pas plus de 400 lignes de code par review
Une code review de 200 à 400 lignes de code (1h-1h30) permet de trouver entre 70 et 90% des défauts. Au delà de 400 lignes notre capacité à trouver des défauts diminue.
Chez Captain Contrat, notre auto-évaluation : 4 / 5
Nous nous sommes fixé une règle chez Captain : si une tâche est trop grosse, c’est qu’il faut regarder si elle peut être découpée en plusieurs tâches plus petites.
On peut également ouvrir plusieurs pull requests (PR) si on trouve qu’une seule sera trop grosse.
Cela nous permet d’éviter de passer trop de temps sur une même PR et de gagner ainsi en agilité, tout en permettant une relecture plus courte et efficace du code.
Pas plus de 500 lignes de code par heure
Au delà de 500 lignes de code par heure la densité de défauts trouvés par ligne de code diminue. Il vaut donc mieux relire moins de lignes de codes sur un même temps pour trouver plus d’erreurs.
Privilégier la qualité par rapport à la quantité et prendre son temps.
Chez Captain Contrat, notre auto-évaluation : 4 / 5
En limitant la taille des tâches, le nombre de ligne de code par PR diminue et donc le nombre de lignes à relire.
On se fixe également comme objectif d’éviter d’ouvrir plus de deux PR à la fois par développeur pour éviter de la charge mentale pour lui et ses reviewers.
Ainsi les reviews se font plus rapidement sans impacter la qualité et sans bloquer le développeur en attente de retours. On évite de s’embourber dans des PR fleuve qui trainent pendant des jours avant d’être acceptées : une bonne PR est une PR mergée en moins de 24h.
Ne pas review pendant plus d’une heure
Notre cerveau a beaucoup de mal à rester concentré plus d’une heure sur une même tâche, il est fortement recommandé de prendre une pause pour maximiser nos chances de trouver les défauts.
Chez Captain Contrat, notre auto-évaluation : 4 / 5
Chaque développeur gère les moments de la journée où il review comme cela l’arrange.
Le but étant de donner une review dans la journée pour ne pas bloquer les autres développeurs.
Cela permet en plus de la taille réduite des PR d’avancer en alternant entre écriture et relecture de code et ne jamais être submergé de relectures à faire.
Ainsi on limite la durée passée à chaque fois que l’on review.
Fixer des objectifs et des métriques
La code review est censée améliorer la qualité du code, fixer des métriques peut permettre de mesurer son efficacité.
Chez Captain Contrat, notre auto-évaluation : 4/5
Les métriques que l’on suit :
- Les issues Code Climate : différents linters (rubocop, eslint, flog) relèvent les infractions aux conventions
- La couverture de test : plus le code est testé automatiquement, moins on a besoin de le tester à la main
- Le nombre de lignes supprimées pour ne pas garder de code inutile
Commenter le code écrit pour faciliter les reviews
L’étude recommande de commenter au maximum le code car cela permet de trouver plus facilement ses propres erreurs et de faciliter le travail de celui qui review tout en défendant ses choix.
Chez Captain Contrat, notre auto-évaluation : 2/5
C’est quelque chose que l’on fait rarement sauf dans les cas où le code est complexe ou inattendu ce que l’on cherche à éviter au maximum.
Le débat reste ouvert au sein de l’équipe entre ceux qui y voient un potentiel intérêt de limiter les allers-retours lors de la review et les autres qui ne veulent pas que ce soit une excuse pour écrire du code trop complexe.
Utiliser des checklists
Les checklists doivent permettre d’éviter les erreurs récurrentes et de ne pas passer à côté d’omissions qui sont ce qu’il y a de plus dur à trouver dans une review.
Ca doit permettre également de fixer ce que l’on attend d’une review.
Chez Captain Contrat, notre auto-évaluation : 3 / 5
Notre checklist pourrait être encore plus complète mais beaucoup de choses sont gérées par les linters qui tournent à chaque push via via notre processus d’intégration continue.
Rendre positive la culture de la code review
La code review implique d’accepter le regard critique des autres développeurs sur son travail. S’il n’est pas vécu de manière positive, cela peut rapidement créer des tensions.
Il est donc important que cela puisse être un levier de collaboration et de progression pour toute l’équipe.
Trouver des défauts dans le code est une opportunité d’améliorer la qualité du code. Cela permet aussi aux profils juniors d’apprendre des profils seniors et insuffler des best practices à tout le monde.
Il est important que le code review reste une manière d’améliorer le code, pas un moyen d’évaluation de performance du collaborateur pour qu’il soit vécu de manière positive.
Chez Captain Contrat, notre auto-évaluation : 4 / 5
Chaque PR est relue par deux autres développeurs. Nous essayons d’avoir toujours un développeur sénior pour relire pour minimiser les défauts.
Dans cette configuration, le deuxième relecteur peut être un junior.
Cela permet de garantir le meilleur code possible tout en permettant aux profils les moins expérimentés de monter en compétence et d’aiguiser leur regard critique sur du code.
L’autre point positif est l’amélioration du bus factor en permettant la montée en compétence par la relecture.
Conclusion
Chez Captain Contrat nous considérons donc la code review comme essentielle dans la garantie de la qualité de notre base de code. Mais pour que cela reste vécu positivement par toute l’équipe, nous nous attachons à garder des principes essentiels :
- Ne pas infliger des codes review trop longues
- Ne juger que le code et pas le développeur
- Tout le monde peut relire le code de tout le monde pour faire progresser l’équipe
Depuis mon arrivée chez Captain Contrat en tant que développeur junior j’ai pu mesurer l’importance de la code review.
Malgré mon niveau j’ai été amené dès le début à relire le code de développeurs seniors et j’ai pu améliorer le code que je produisais grâce aux reviews qu’ils me faisaient.
Cela m’a permis de prendre confiance et de progresser beaucoup plus rapidement que si j’avais dû développer seul dans mon coin.
Si ça vous tente de faire des code reviews avec nous, on recrute !
