Les équipes agiles sont autonomes, avec des profils de compétences qui couvrent l'ensemble de l'équipe. C'est possible, en partie, grâce à la revue de code. La revue de code permet aux développeurs d'apprendre la base du code, ainsi que les nouvelles technologies et techniques qui leur permettront de faire évoluer leurs compétences.
Mais en quoi consiste précisément la revue de code ?
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.
Quels sont les avantages pour une équipe agile ?
Chaque équipe, quelle que soit sa méthodologie en matière 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. Aucun membre de l'équipe n'est le seul à connaître une partie donnée de la base du code. En termes simples, la revue du code facilite le partage de connaissances sur l'ensemble de la base de code et 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 l'« élément incontournable ». Les ingénieurs complets sont capables de traiter aussi bien des tâches de première ligne que des tâches au niveau du serveur.
La revue de code optimise les estimations
Vous vous souvenez de la section consacrée aux estimations ? L'estimation est un exercice d'équipe. Or, une équipe réalisera de meilleures estimations si les connaissances liées au produit sont diffusées en son sein. Lorsque de nouvelles fonctionnalités sont ajoutées au code existant, le développeur initial peut fournir un feedback et une estimation raisonnables. De plus, n'importe quel réviseur de code est exposé à la complexité, aux tickets connus et aux préoccupations concernant cet aspect de la base de code. Le réviseur de code partage ensuite les connaissances du développeur initial à propos de cette partie de la base de code. Cette pratique génère différents avis informés qui, lorsqu'ils sont utilisés pour réaliser une estimation finale, rendent toujours celle-ci plus solide et 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 pendant 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.
Gardez à l'esprit que la revue de code ne consiste pas uniquement à faire réviser, par un membre plus expérimenté, le code d'un nouveau venu. La revue de code doit être effectuée au sein de l'équipe et dans tous les sens. La connaissance n'a pas de limites ! Certes, la revue de code peut aider les nouveaux ingénieurs, mais en aucun cas elle ne doit être utilisée comme seul exercice de mentorat.
Toutefois, la revue de code prend du temps !
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 !
