Comment devrait se dérouler une revue de code? Vous avez certainement eu à relire du code d’un autre programmeur afin de lui donner des commentaires. Qu’est-ce qu’on regarde? Quels sont les critères qui devraient être appliqués lorsque vous faites cette revue?
Tant de questions et une multitude de réponses. Je pense qu’il n’y a pas un programmeur qui va donner une réponse exactement identique. La programmation est tellement une activité libre pouvant être laissée au goût de chacun que ça varie énormément.
Par expérience, une revue systématique des changements qui sont produits avant la mise en production doit avoir lieu. Cette étape doit être obligatoire. Un collègue doit obligatoirement avoir jeté un coup d’œil à votre code et procédé aux tests de vos changements pour aller de l’avant.
Je me suis déjà prononcé dans le passé sur le sujet. À mon avis, tout débute par la qualité du code qui a été produit. La qualité de la solution réalisée sera directement liée à la qualité du code qui aura été développée. Cet impact est à plusieurs niveaux. Par exemple, une solution jetable sans égard à la séparation des responsabilités des différentes couches applicatives aura de la difficulté à évoluer avec le temps. Ou même, du code pas très propre avec, par exemple, des structures de données inappropriées sera difficile à comprendre à long terme.
À faire lors d’une revue de code
L’intention
La première question à se demander, en tant que reviewer, est la suivante: est-ce que, à la première lecture, êtes-vous en mesure de deviner l’intention de votre collègue dans sa résolution de problème? En aucun cas vous ne pouvez permettre de vous dire « Ah, oui, c’est bon c’est X qui a codé ça. Ce n’est pas beau, mais ça va aller ». Si c’est incohérent, incompréhensible ou simplement pas au niveau, ça doit retourner à la planche de dessin.
Première lecture
Il devrait être simple de faire une lecture rapide du code qui a été soumis et de comprendre le problème à résoudre. Une première lecture du code peut révéler certains détails que l’auteur n’a pas vus pendant le développement. Plusieurs éléments qui pourraient retenir votre attention ici.
Quelques exemples :
- Est-ce que la convention de nommage utilisée représente bien le domaine d’affaires?
- Y a-t-il est méthodes trop longues? En général une méthode doit faire quelques lignes, tout au plus.
- Le code, qui a été ajouté (ou retiré), est-il au bon endroit?
- Remarquez-vous de la duplication de code?
Signalement
Afin de ne rien oublier, notez et compilez tout ce que vous pouvez remarquer. Révisez par cette liste par la suite. Le travail de correction de votre collègue sera grandement simplifié si vous structurez vos remarques en sections logiques.
Par le fait même, considérez le facteur humain dans toute l’activité. Dans vos commentaires, mettez de l’emphase sur le code et vos suggestions pour améliorer ce qui a été produit. Les tournures de phrases comme « ton code » ou « tes changements » sont définitivement à éviter.
Une convention
Une convention de code permet d’émettre des lignes directrices qui servent à guider les développeurs dans leur prise de décision pour structurer leurs solutions. Il s’agit aussi de permettre d’unifier le design de l’application au goût de chacun selon l’humeur du moment.
Le plus important avec la convention de code est de promouvoir les meilleures pratiques avec votre langage de programmation. Il ne s’agit pas juste d’un exercice de style. Il faut tirer profit au maximum des fonctionnalités du langage que vous utilisez et aussi de vous protéger des moins bons côtés.
Cet aspect est à la base de tout. Cette convention doit être adoptée par tous et enseignée aux programmeurs se joignant à l’équipe.
D’ailleurs, si vous cherchez une base pour vous inspirer. Jetez un coup d’oeil à la section Framework Design Guidelines sur MSDN.
À valider
Indépendamment de la convention que vous employez, il y a quand même certains essentiels à regarder pour s’assurer que ce qui a été développé a un certain niveau de qualité.
- Le code doit être clair et sans équivoque. Les variables sans acronymes. Les méthodes avec un nom concis, représentant ce qu’elle tente d’accomplir.
- Les acronymes KISS, DRY et YAGNI ont leur raison d’être.
- Viser un respect des principes SOLID. Ce n’est pas toujours évident, mais c’est un objectif à cibler.
- Est-ce que les validations pour la valeur NULL ont été effectuées là où c’est nécessaire?
- En cas d’erreur, l’application s’assure-t-elle de gérer ces erreurs convenablement. C’est à dire sans planter de façon catastrophique?
- Toujours favoriser la lisibilité en faveur de la concision en ce qui a trait aux noms dans le code. (MSDN)
- Valider le respect du rôle et responsabilité des différentes couches (Contrôleur, Vue, Service, Repository, DTO, Factory, etc)
- Est-ce que le flow du code et la détection des erreurs est cohérent? Une méthode qui a une succession de if et/ou switch imbriqués ou plusieurs instructions return devrait générer une attention particulière.
- Est-ce que les frameworks et librairies utilisées sont employés de la bonne façon et dans leur bon contexte?
- Le choix des structures de données et algorithmes est-il approprié dans le contexte? Cela peut avoir un impact significatif sur la rapidité d’exécution de votre application.
Références
French Coding 