On a testé la "Code review quotidienne synchronisée".

La fameuse code review, tout le monde est d'accord pour dire qu'elle est encouragée et que c'est une super bonne pratique ! Si chacun peut citer au moins l'un de ses bénéfices, dans les faits, peu de professionnels y ont recours régulièrement ou du moins en profondeur.

‍

Trop souvent, elle va passer à la trappe à cause d'une prise de retard sur un projet ou d'autres tâches urgentes à finaliser.

‍

Chez Skello, pour éviter que cette code review soit constamment dépriorisée face aux différentes tâches qui incombent aux développeurs, nous avons décidé de consacrer un créneau quotidien commun à sa pratique.

‍

☑️ Trouver le temps

‍

On dit toujours que si on veut passer du temps sur quelque chose, il faut lui faire une place claire et nette dans nos agendas. Sans quoi, son tour ne viendrait jamais. Et c'est ce que nous avons fait !

‍

Nous avons choisi un créneau commun à tous les développeurs, quelque soit leur équipe : une heure de 14h à 15h est consacrée à la code review. Cela se fait juste après le daily standup de sorte qu'en allant lire les PR (Pull Request) ouvertes, nous ayons un minimum de contexte oral sur ce qu'on va y trouver. Ces daily se faisant par équipe, vous vous demandez probablement si nous nous limitons à la review des PR de notre propre équipe.

‍

La réponse est : Non, toutes les PR sont review par tout le monde.

‍

👊 Comment on review

‍

En plus du contexte dont on parle à l'oral au daily, nous pouvons retrouver nous-mêmes du contexte via les liens vers les tickets dans la PR en elle-même. De plus, plusieurs actions sont possibles même si on ne connaît pas particulièrement le projet : inspecter la propreté du code ou suggérer du code alternatif qui fait la même chose mais qui soit plus adapté ou plus optimisé en sont deux exemples.

‍

Une PR doit être approuvée par au moins deux développeurs pour passer du statut Awaiting Feedback (ou en attente de retours) à Valid for Tech (ou valide techniquement). Chez Skello, la qualité du code nous tient particulièrement à cœur 🤓

‍

Le revers de la médaille ? Comme une heure spécifique est dédiée pour la review, ça peut décourager les développeurs d'en faire en dehors de ce créneau. Par conséquent, cela rallonge le temps de review.

‍

Prenons pour exemple Lili la licorne 🦄  : Lili a une PR en cours, elle reçoit des commentaires pendant cette heure par différentes personnes. Elle adapte son code mais doit attendre le lendemain pour les validations ou retours supplémentaires.

‍

Pour contrer cet effet de bord, nous encourageons vivement Lili à relancer les personnes qui ont précédemment review. Ça accélèrera la validation et elle pourra faire avancer son ticket vers la validation produit.

‍

En somme, le créneau dédié à la review n'est pas là pour la limiter à ce moment spécifique, mais plutôt pour assurer qu'il y en ait un minimum de manière régulière, même sur une journée particulièrement chargée. Chez Skello, on joue collectif ! On trouve le temps pour lire le code des autres et se faire des retours. Tout le monde y trouve son compte 💪🏻

‍

😃 Les bénéfices

‍

Pour un nouvel arrivant :

‍

• Recevoir des retours sur les guidelines appliquées au sein de l'entreprise. Ces dernières ont été décidées collectivement et toutes consignées dans notre outil collaboratif Notion. Cela permet à tous les développeurs de produire du code propre et homogène et éviter les débats répétitifs. Toutes ces règles ont été implémentées dans les linters.
• Recueillir des avis sur la pertinence de notre solution de développeurs qui ont une meilleure connaissance du projet et qui travaillent dessus depuis des années.
• Apporter un regard neuf sur la façon de faire globale en commentant à son tour les PR.
• Avoir son avis écouté, valorisé et pris en compte dès le premier jour.

‍

Pour tout le monde :

‍

• Obtenir des conseils personnalisés par des développeurs plus ou moins expérimentés que nous.
• Etre dans un état d'esprit de constante amélioration grâce aux retours constructifs donnés sur nos propres productions.
• Améliorer son esprit critique à force de review le code des autres.
• Améliorer sa capacité à expliquer ses choix techniques en participant à des débats sur la meilleure solution d'aboutir à un certain résultat.
• Distinguer les bouts de code pouvant induire une forte complexité et donc une dégradation des performances de l'application et les prévenir à temps.
• S'instruire en lisant les retours des autres sur des bouts de code différents des nôtres.
• Enfin, ça permet à chacun d'avoir de la visibilité sur les projets des autres équipes ce qui peut être très utile. Par exemple si l'un de nous doit développer quelque chose de similaire, il peut se référer à une PR qu'il a review ou son auteur pour des conseils.

‍

Le petit bonus transparence : Créer une channel Slack (ou tout outil de messagerie utilisé chez vous) avec un bot qui l'alimente avec chaque commentaire fait contenant le lien vers la PR en question. Cela permet d'encourager les autres à en faire, de suivre les discussions qui ont lieu et d'y participer. Ou simplement, dans une logique pédagogique, vous pouvez être curieux de voir le bout de code concerné et la remarque associée !

‍

💡 Le mot de la fin

‍

Dans les équipes tech Skello, nous avons toujours fait de la revue de code. Mais cette idée de créneau commun quotidien est un process assez récent que nous avons voulu tester sur une période de six mois. Résultat ? Les retours sont ultra positifs ! Nous continuons donc à la pratiquer pour tout ce que cela nous apporte au quotidien : nous tirer tous les uns les autres vers le haut en toute bienveillance.