Que sont les revues de code et comment permettent-elles réellement de gagner du temps

Lorsqu'un développeur a fini de travailler sur un ticket, un autre passe en revue le code en se posant les questions suivantes :

• Le code présente-t-il des erreurs logiques évidentes ?

• Après examen des exigences, tous les cas ont-ils été complètement mis en œuvre ?

• Les nouveaux tests automatisés sont-ils suffisants pour le nouveau code ? Les tests automatisés existants doivent-ils être réécrits pour intégrer les modifications apportées au code ?

• Le nouveau code est-il conforme au guide stylistique actuel ?

La revue de code doit s'intégrer au processus existant de l'équipe. Par exemple, si une équipe utilise des workflows de création de branches de tâches, démarrez une revue de code une fois que l'ensemble du code a été écrit et que des tests automatisés ont été effectués et réussis, mais avant le merge du code en amont.

Cela permet de s'assurer que le réviseur du code consacre son temps à vérifier les aspects manqués par les machines et évite que de mauvaises décisions de programmation viennent polluer la ligne de développement principale.

Chaque équipe, quelle que soit sa méthodologie de développement, peut tirer parti d'une revue du code. Cependant, les équipes Agile peuvent en retirer des avantages substantiels, étant donné que le travail y est décentralisé à tous les niveaux.

Personne n'est le seul à connaître une partie précise de la base du code. Autrement dit, les revues de code contribuent à faciliter le partage des connaissances relatives à la base de code au sein de l'équipe.

La revue de code permet le partage des connaissances

Toutes les équipes Agile affichent une flexibilité imbattable, à savoir la capacité à extraire des tâches du backlog et à les faire exécuter par tous les membres de l'équipe. Ces équipes sont ainsi mieux à même de « swarmer » sur les nouvelles tâches, car personne n'est considéré comme le « chemin critique ».

Les ingénieurs full stack peuvent s'occuper du travail front-end et côté serveur.

La revue de code optimise les estimations

Vous vous souvenez de la section sur les estimations ? L'estimation est un travail d'équipe. Grâce à elle, l'équipe peut réaliser de meilleures estimations en répartissant la connaissance des produits au sein de l'équipe.

Au fur et à mesure que de nouvelles fonctionnalités sont ajoutées au code existant, le développeur d'origine peut fournir de bons commentaires et estimations. En outre, tout réviseur de code est également exposé à la complexité, aux problèmes connus et aux préoccupations de cette partie de la base de code.

Le réviseur de code partage donc les connaissances du développeur initial de cette partie de la base de code. Cette pratique crée de multiples entrées éclairées qui, lorsqu'elles sont utilisées pour une estimation finale, renforcent cette estimation et la rendent encore plus fiable.

La revue de code vous permet de vous absenter

Personne ne veut être le seul et unique point de contact pour une portion de code. De même, personne n'a envie de se plonger dans une portion de code critique qu'il n'a pas lui-même écrite, surtout s'il s'agit d'une urgence au niveau de la production.

La revue de code permet de partager les connaissances au sein de l'équipe, afin que n'importe lequel de ses membres puisse prendre les rênes et continuer à diriger le navire. (Chez Atlassian, on adore mélanger les métaphores !) Seulement voilà : si aucun développeur n'est considéré comme le chemin critique, cela signifie également que les membres de l'équipe peuvent s'absenter lorsqu'ils en ont besoin.

Si vous êtes cloué à votre bureau à cause du système de contrôle des versions, la revue de code est un excellent moyen de retrouver votre liberté. La liberté de prendre ces vacances bien méritées ou de consacrer votre temps à un autre aspect du produit.

La revue de code permet de former les nouveaux ingénieurs

L'un des aspects particuliers de l'agilité est que, lorsqu'un nouvel arrivant rejoint l'équipe, les ingénieurs plus chevronnés l'accompagnent et le forment. Or, la revue de code facilite les conversations autour de la base de code.

Souvent, les équipes cachent certaines connaissances dans le code qui refont surface lors de la revue de code. Les nouveaux arrivants, qui ont un œil neuf sur tout cela, découvrent, dans la base du code, certains aspects délicats ou mal évalués qui ont besoin d'une nouvelle perspective. Ainsi, la revue de code permet également de tempérer les nouveaux avis au moyen des connaissances déjà en place.

Bien sûr, qu'elle prend du temps. Mais ce n'est pas du temps perdu, bien au contraire.

Voici trois conseils d'optimisation : 

Partagez la charge

Chez Atlassian, bon nombre d'équipes ont besoin de deux revues de code, quel que soit ce code, avant de l'enregistrer dans la base de code. Cela vous semble être une charge de travail excessive ? Cela ne l'est pas. Du tout. Lorsqu'un auteur sélectionne des réviseurs, il ratisse large dans l'ensemble de l'équipe. Deux ingénieurs, quels qu'ils soient, peuvent donner leur avis. Le processus est ainsi décentralisé afin que personne ne devienne un goulot d'étranglement. De plus, cela garantit une bonne couverture au sein de l'équipe pour ce qui est de la revue de code.

Révisez avant le merge

En exigeant une revue de code avant un merge en amont, vous vous assurez qu'aucun code n'est enregistré sans revue. Ainsi, les décisions architecturales douteuses prises à 2 h du matin et l'utilisation inadéquate d'un schéma d'usine par le stagiaire seront décelées avant qu'elles ne risquent de produire un impact durable (et regrettable) sur votre application.

Utilisez la pression de vos collègues à votre avantage

Lorsque les développeurs savent que leur code sera révisé par un collègue, ils font un peu plus attention afin de s'assurer de la réussite de tous les tests de code et de la conception parfaite du code pour en faciliter la revue. Cette attention accrue a également tendance à fluidifier le processus de programmation et, au final, à l'accélérer.

N'attendez pas la revue de code si vous avez besoin d'un feedback plus tôt dans le cycle de développement. Un feedback précoce améliore souvent le code. Par conséquent, ne soyez pas timide et impliquez les autres, dès que vous le pouvez. Cela optimisera votre travail et vos collègues n'en deviendront que meilleurs dans la revue de code. C'est un cercle vertueux !