La revue de code ou code review est un processus permettant à un développeur relecteur de donner des retours sur le travail d'un autre développeur auteur.

L'objectif de cette manoeuvre est d'améliorer la qualité de code (code quality) globale et d'identifier des bugs.

Le code peut être revu :

• - en pair programming, comme c'est le cas dans le cadre de la méthodologie de projet Extreme Programming (XP), où deux développeurs vont revoir le code en même temps côte à côte sur le même écran ou bien à distance en écran partagé

• - directement par le développeur qui fait la revue de code, comme c'est le cas par exemple lorsque notre CTO revoit le code d'un développeur moins expérimenté via une Pull Request (PR) sur github. Si la PR est validée, le code développé pourra rejoindre le reste de la codebase (par exemple sur l'environnement de développement ou de production)

Avant de vous lancer tête baissée dans la revue de code, il est important de se poser des questions sur le contexte de cette code review.

S'agit-il de :

• Vérifier que le code à revoir répond à un besoin particulier par exemple dans le cadre d'une Pull Request (PR) à revoir ?

• Se faire une idée rapide de vérifier les compétences techniques et la qualité globale du code produit par une équipe de développement ?

• Vous assurer de pouvoir reprendre le code d'un ancien développeur sur le départ ?

Une fois l'objectif de la revue est clair, vous pouvez démarrer en testant si le code source récupéré s'exécute bien.

Passe-t-il les Tests Unitaires (TU) / Tests Automatisés ? Y'a-t-il des erreurs du linter, de prettier (formatteur de code) ou de SonarQube (logiciel de qualimétrie) ?

Si le code passe cette première étape, vous pouvez tester son fonctionnement pour vous assurer que ce qui a été implémenté fasse bien ce qui a été spécifié peut importe le device et navigateur moderne utilisé (Safari, Google Chrome, Firefox...).

Il est important dans le cadre de développements front-end, de vous assurer du respect des éventuelles maquettes designées, mais également de vérifier le responsive, c'est-à-dire que le développement fonctionne bien et soit facilement utilisable sur ordinateur mais également sur les supports tablette et téléphone mobile.

Cela fonctionne en environnement de test? Super, vous allez pouvoir faire une première passe sur le code pour vous faire une première impression sur la qualité du code-source et vérifier sa maintenabilité.

Si vous essayez de vous faire une idée sur le niveau du développeur dont vous revoyez le code, gardez également en tête le contexte dans lequel le développeur qui vous soumet son code a travaillé : a-t-il été mis sous pression pour privilégier la vélocité à la qualité et sortir le produit rapidement au lieu de refactoriser son code ? Y'a-t-il eu des changements brusques de décisions de la part du product owner, CTO ou client pendant le développement ? A-t-il dû reprendre des bases de code existant ou créer tout de zéro ?

Si vous êtes limités par le temps et qu'à ce stade là vous avez déjà des premières remarques, vous pouvez déjà faire vos retours au développeur en le concertant.

Si vous disposez de plus de temps, vous allez pouvoir rentrer plus en profondeur dans le code et le passer au peigne fin pour trouver les éventuelles erreurs de style, potentiels bugs mais également les améliorations à faire pour simplifier le code.

Assurez-vous également que le code que vous revoyez n'introduit pas de régressions.

Si vous apercevez des soucis mineurs comme des fautes de frappe, vous pouvez les communiquer au développeur au fur et à mesure, en revanche, si vous apercevez des choses qui conduiraient à des modifications majeures, il peut être bien de se poser la question de pourquoi vous souhaitez proposer ces modifications, et si elles sont bien justifiées, d'en discuter directement avec l'auteur du code lors d'un point dédié.

Lorsque vous proposez des choses au développeur auteur des développements, pour que celui-ci puisse améliorer son code, soyez bienveillant !

Il est important de ne pas froisser le développeur qui a produit le code que vous revoyez en faisant vos remarques de façon négative !

On peut tout à faire relever un problème de façon positive avec une tournure de type "Intéressant, mais as-tu pensé à consulter nos coding guidelines (règles de codage) qui proposent de..." au lieu d'asséner un brutal "NON, ÇA NE RESPECTE PAS NOS GUIDELINES ! RTFM !" 😅

Dans le même état d'esprit, n'hésitez pas à saluer des pratiques qui auraient été mises en place par le développeur suite à vos commentaires sur une code review passée ;)

Vous avez maintenant les clés pour faire de bonnes code reviews, n'oubliez pas, la patience, la pédagogie et le partage de connaissance font partie des clés pour avoir une équipe de développeurs épanouis dans leur travail !

Besoin d'une équipe externe pour auditer votre code ?

Notre agence de développement Blacksmith peut s'en charger et vous aider à mettre en place des bonnes pratiques de code ! Contactez-nous à partners@blacksmith.studio !