Les quatre types de revue de code

À présent, nous vous présentons les quatre types de revues de code et leurs applications. Chacun a des avantages et faiblesses selon les besoins spécifiques de vos équipes. 

Au programme :

• Choisir un type de revue de code
• Revue instantanée
• Revue asynchrone
• Revue synchrone
• Revue d’équipe

Choisir le bon type de revue

Il est essentiel de choisir une méthode qui correspond aux forces et aux faiblesses de votre équipe. Cela dépendra de différents facteurs propres à votre organisation. Si votre équipe est répartie sur plusieurs fuseaux horaires par exemple, vous feriez mieux d’adopter une revue asynchrone.

Voyons quelques exemples :

• Revue asynchrone : Si votre équipe est répartie sur plusieurs fuseaux horaires, la revue asynchrone serait un choix idéal, car elle permet une certaine flexibilité.
• Revue instantanée ou synchrone : Il s’agit d’une excellente option si votre équipe de développement avance rapidement et gère des lancements de haute priorité.
• Revue d’équipe ad hoc : En cas de modifications majeures apportées à la base de code par un développeur, une revue d’équipe ad hoc aide à encadrer le cycle de rétroaction.

Revues de code chez Levio

Par défaut, Levio utilise la méthode asynchrone à l’interne, principalement parce que nous utilisons le contrôle de version GitHub. L’avantage est que l’auteur et le réviseur sont indépendants, ce qui évite la nécessité d’une présence simultanée tout en favorisant la parallélisation des flux de travail. Les notes et les commentaires formulés pendant le processus de revue sur GitHub font également office de documentation. Bien que cette approche soit bien adaptée à notre structure de développement, nous ne nous y limitons pas.

Examinons les raisons qui pourraient vous inciter à choisir un type de revue de code plutôt qu’un autre.

Revue instantanée

La revue instantanée s’impose :

• lorsque l’échéance est serrée;
• si au moins deux membres de l’équipe possèdent des compétences équivalentes de développeur/réviseur.

Avantages : Tout se fait rapidement, y compris le développement, la revue et les tests.

Inconvénients : Le hic est au niveau de la documentation. Cette méthode peut également donner lieu à une conception bâclée puisque l’accent est mis sur la vitesse.

Revue asynchrone

Le processus asynchrone pourrait vous convenir si :

• des conflits de planification entravent les rencontres en personne;
• votre équipe est dispersée aux quatre coins du globe;
• vous utilisez déjà GitHub.

Avantages : Cette méthode découple l’auteur et le réviseur, permettant à ce dernier de réaliser les revues en fonction de son emploi du temps tout en assurant une autodocumentation avec GitHub.

Inconvénients : Le temps de réponse du réviseur peut créer un goulot d’étranglement. De plus, sans la réactivité des revues instantanées ou synchrones, certains changements importants pourraient être manqués s’ils ne sont pas signalés au bon moment par leur auteur.

Revue synchrone

La revue synchrone est idéale dans les situations suivantes :

• pour mettre le réviseur à jour sur le projet, notamment avec un nouveau développeur ou un développeur débutant déjà familiarisé avec le code;
• lorsqu’il faut respecter une échéance serrée ou corriger un bogue de haute priorité;
• pour tout changement qui doit être mis en œuvre rapidement.

Avantages : Cette revue peut allier profondeur et rapidité si le réviseur connaît déjà bien le projet.

Inconvénients : Le revers de la médaille est que le réviseur pourrait valider une modification à la va-vite.

Revue d’équipe

Les revues d’équipe sont idéales dans des situations très précises où :

• la disponibilité des ressources ne pose pas de problème, permettant des rencontres de trois personnes ou plus;
• vous avez la possibilité d’assigner différents rôles au sein du groupe de réviseurs.
• Exemple : Une personne peut se charger de prendre des notes, de documenter les problèmes et d’en évaluer la gravité pendant la discussion.

Avantages : Le nombre accru de participants conduit à des analyses plus poussées. Les revues collectives encouragent l’analyse sous différents angles, ce qui augmente les chances de repérer les défauts. Elles ont l’avantage de familiariser un grand nombre de personnes avec le code.

Inconvénients : Certains membres de l’équipe peuvent manquer de connaissances spécialisées pour effectuer une revue adéquate ou ne pas être suffisamment préparés. Cette méthode devrait être utilisée avec modération, car elle requiert beaucoup de ressources, tous les membres devant réserver un créneau commun dans leur emploi du temps.

Prochaines étapes : Améliorer vos revues de code

Choisir le bon type de revue pour votre équipe de développement optimisera le rendement de toute l’équipe, surtout si vous le combinez à des modèles de pratiques exemplaires et à des listes de contrôle personnalisées.