Comment organiser une review de code simple, efficace et rapide
Dans une équipe qui applique les bonnes pratiques de l’Intégration Continue (CI), une fonctionnalité développée et sauvegardée qui a fait l’objet d’un pull request (cas de git) doit aussi faire l’objet d’une review par les autres développeurs plus ou moins expérimentés afin de s’assurer d’un certain niveau de qualité au niveau du code qui demande à être intégré.
Cette review se présente avec différentes contraintes qui sont les délais de livraison, le manque de temps et d’informations sur la fonctionnalité à review. Mais, ces contraintes ne doivent pas être une excuse pour ne pas la planifier car, elle est de nos jours l’une des étapes importantes et incontournables dans tout processus de développement logiciel et surtout dans les méthodes agiles et d’intégration continue.
Si vous me lisez c’est que vous vous êtes déjà demandé comment faire votre review le plus simple possible, alors installez-vous !!!
LA REVIEW SIMPLE, OU A PLUSIEURS ?
Avant toute chose il faut choisir comment procéder à la review. Cette étape importante et inévitable est une contrainte majeure que toute équipe de développement doit mettre en place.
Quel type de review choisir pour mon équipe ?
La réponse à cette première question est primordiale car elle sera l’une des étapes qui pourrait entraîner les contraintes liées à la review qui sont :
- Le délai de livraison
- Le coût du développement
- Amélioration de l’existant
- Le temps de mise en place de la review
- Etc..
La review de code pourrait se faire par un seul développeur ou par un groupe de développeur.
Dans le premier cas, il serait préférable que le reviewer soit un développeur ayant une bonne connaissance ou compréhension du projet. La review par un seul développeur est moins coûteux mais les détections des bugs, l’amélioration de l’existant sont moindres et le temps de mise en place pour la review est très élevé. Ce qui pourrait être désavantageux pour le développement futur d’autres fonctionnalités liées à cette dernière.
Dans le second cas, le coût, la détection de bugs et l’amélioration de l’existant sont élevés et donc seront une contrainte au développement et à la livraison du logiciel. Le temps de mise en place pour la review est presqu’insignifiant.
Le choix du type de review de code lors d’un développement logiciel implique donc une bonne réflexion. Ci-dessous un exemple de tableau comparatif des types SIMPLE ou DOUBLE pour la review.
Nous constatons qu’une review simple est moins coûteuse que celle d’un double. Par contre le temps de mise en place pour la review SIMPLE est le triple de la DOUBLE.
LA REVIEW PAR UN NOVICE OU UN EXPÉRIMENTÉ ?
Avec l’évolution rapide de la technologie de nos jours, l’on apprend toujours de quelqu’un. La review effectuée par un novice et un expérimenté ou en groupe permettra de combler plus ou moins toutes les faces d’une relecture. Tout développeur novice ou expérimenté a sa propre expérience, sa manière de voir et de comprendre le code. Ses différents regards permettent d’améliorer le code mais aussi de mettre en place les bases d’une autre fonctionnalité liée à cette dernière et donc faire gagner l’équipe en expérience.
La review par un novice qui est en contact pour la première fois avec le langage ou qui est débutant qui ne trouve rien à dire, elle lui pourrait être bénéfique pour la compréhension et l’apprentissage du langage mais il ne faut pas conclure qu’il y a pas de bugs et qu’il n’y a rien à revoir.
Une fois que vous avez choisi ces différents critères, comment se passe une review de code et que doit-on regarder ?
COMMENT SE PASSE LA REVIEW DE CODE ET QUE DOIT-ON REGARDER ?
Pour tout langage, pour écrire du code qui exploite au mieux toutes ses capacités, différentes règles s’imposent aux développeurs et qu’il faut respecter pour mettre en place les bonnes pratiques du langage. Voici quelques règles que vous pouvez mettre en place dans le cas du framework ANGULAR :
- Ecrire le code typescript dans un fichier séparé avec l’extension .ts
- Écrire le code html dans un fichier avec l’extension .html
- Initialiser les variables avec le bon type en début de script
- Bien nommer les variables et fonctions
- Expliciter les dépendances
AUTRES POINTS A VERIFIER
Relire son code même après validation doit être un réflexe pour tout développeur. La relecture vous permettra de déceler certaines failles que la review n’a pu voir. Les points qu’il ne faut pas passer à côté sont :
- La sécurité
- L’existence d’une variable ou d’un index (dépend du langage). Mais combien de fois vous retrouverez ce fameux undefined index
- La compréhension algorithmique (qui va de pair avec la compréhension du code souvent)
La review et la relecture demandent du temps donc prenez votre temps ! Quoi qu’il arrive, on ne peut pas faire des choses de qualité dans un temps très restrictif. Voilà! Nous sommes arrivé à notre point de chute. Merci de votre lecture et à la prochaine fois.
