J’effectue des revues de code au quotidien depuis plus de dix ans maintenant. Les avantages des revues de code sont nombreux : quelqu’un vérifie ponctuellement votre travail pour détecter les erreurs, il apprend de votre solution, et la collaboration aide à améliorer l’approche globale de l’organisation en matière d’outillage et d’automatisation. Si vous ne procédez pas actuellement à des revues de code dans votre organisation, commencez dès maintenant. Cela fera de chacun un meilleur ingénieur.
De nombreuses personnes et organisations ont partagé leurs meilleures pratiques de revue de code et ce que la définition de bonnes revues de code signifie pour elles. Les guides de Google, de l’équipe SmartBear et de l’ingénieur Philipp Hauer sont tous d’excellentes lectures. Voici mon point de vue personnel sur ce que sont de bonnes revues de code et comment les améliorer au niveau de l’équipe et de l’organisation. Ceci dans le contexte de l’environnement technologique dans lequel j’ai travaillé – actuellement chez Uber, et avant cela chez Skype/Microsoft et Skyscanner.
Les bonnes revues de code sont la barre vers laquelle nous devrions tous tendre. Elles couvrent les meilleures pratiques communes et faciles à suivre avec lesquelles toute équipe peut commencer, tout en assurant des revues de haute qualité et utiles à long terme.
Les meilleures revues de code sont celles où les ingénieurs continuent d’améliorer la façon dont ils font les revues de code. Ces revues de code examinent la modification du code dans le contexte de la base de code, de qui la demande et dans quelle situation. Ces revues adaptent leur approche en fonction du contexte et de la situation. Le but étant non seulement d’obtenir une revue de haute qualité, mais aussi d’aider les développeurs et les équipes qui demandent la revue à être plus productifs.
Domaines couverts par la revue de code
Les bonnes revues de code examinent la modification elle-même et la façon dont elle s’intègre dans la base de code. Elles examinent la clarté du titre et de la description et le « pourquoi » du changement. Ils couvrent l’exactitude du code, la couverture des tests, les changements de fonctionnalité, et confirment qu’ils suivent les guides de codage et les meilleures pratiques. Ils signalent les améliorations évidentes, comme le code difficile à comprendre, les noms peu clairs, le code commenté, le code non testé ou les cas limites non gérés. Ils noteront également quand trop de changements sont entassés dans une seule revue, et suggéreront de garder les changements de code à usage unique ou de diviser le changement en parties plus ciblées.
Les meilleures revues de code examinent le changement dans le contexte du système plus large, et vérifient que les changements sont faciles à maintenir. Elles peuvent poser des questions sur la nécessité du changement ou sur son impact sur d’autres parties du système. Ils examinent les abstractions introduites et la manière dont elles s’intègrent dans l’architecture logicielle existante. Ils notent les observations relatives à la maintenabilité, telles que la logique complexe qui pourrait être simplifiée, l’amélioration de la structure des tests, la suppression des doublons et d’autres améliorations possibles. L’ingénieur Joel Kemp décrit les grandes revues de code comme un passage contextuel après un premier passage léger.
Ton de la revue
Le ton des revues de code peut grandement influencer le moral des équipes. Les revues au ton dur contribuent au sentiment d’un environnement hostile avec leurs microagressions. Un langage empreint d’opinions peut mettre les gens sur la défensive et susciter des discussions animées. Dans le même temps, un ton professionnel et positif peut contribuer à un environnement plus inclusif. Les personnes qui évoluent dans ces environnements sont ouvertes aux commentaires constructifs et les revues de code peuvent au contraire déclencher des discussions saines et animées.
Les bonnes revues de code posent des questions ouvertes au lieu de faire des déclarations fortes ou pleines d’opinion. Elles offrent des alternatives et des solutions de contournement possibles qui pourraient mieux fonctionner pour la situation sans insister sur le fait que ces solutions sont la meilleure ou la seule façon de procéder. Ces revues supposent que le réviseur peut manquer quelque chose et demandent des clarifications plutôt que des corrections.
Les meilleures revues de code sont également empathiques. Elles savent que la personne qui écrit le code a consacré beaucoup de temps et d’efforts à cette modification. Ces revues de code sont gentilles et sans prétention. Elles applaudissent les bonnes solutions et sont positives dans l’ensemble.
Approuver vs demander des modifications
Une fois qu’un réviseur a terminé sa révision, il peut soit la marquer approuvée, soit bloquer la révision avec des demandes de modification, soit ne pas définir de statut spécifique, la laissant dans un état « pas encore approuvé ». La façon dont les réviseurs utilisent les statuts approuver et demander des changements est révélatrice des revues de code.
Les bonnes revues de code n’approuvent pas les changements alors qu’il y a des questions ouvertes. Cependant, ils indiquent clairement quelles questions ou commentaires sont non bloquants ou sans importance, en les marquant distinctement. Elles sont explicites lorsqu’elles approuvent un changement – par exemple en ajoutant un commentaire du type « ça a l’air bien ! ». Certains endroits utilisent des acronymes comme LGTM – ceux-ci fonctionnent également, mais soyez conscient que les nouveaux arrivants pourraient interpréter ces acronymes d’initiés pour autre chose. Les bonnes revues de code sont tout aussi explicites lorsqu’elles demandent un suivi, en utilisant l’outil de revue de code ou la convention d’équipe pour le communiquer.
Les meilleures revues de code sont fermes sur le principe mais flexibles sur la pratique : parfois, certains commentaires sont adressés par l’auteur avec un changement de code séparé et de suivi. Pour les changements plus urgents que d’autres, les réviseurs essaient de se rendre disponibles pour des révisions plus rapides.
De la revue de code à se parler
Les revues de code se font généralement de manière asynchrone et par écrit via un outil de revue de code. C’est généralement par commodité, pour permettre des revues de code à distance, et pour permettre à plusieurs personnes de revoir la même modification de code. Mais quand est-il temps d’arrêter d’utiliser l’outil – aussi bon soit-il – et de commencer à parler du code en face à face ?
Les bonnes revues de code laissent autant de commentaires et de questions que nécessaire. Si la révision ne les aborde pas toutes, ils les notent également. Lorsque la conversation se transforme en un long va-et-vient, les réviseurs essaieront de passer à une discussion avec l’auteur en personne au lieu de brûler plus de temps en utilisant l’outil de révision du code.
Les meilleures révisions de code entreront en contact de manière proactive avec la personne qui effectue la modification après avoir fait un premier passage sur le code et avoir beaucoup de commentaires et de questions. Ces personnes ont appris qu’elles gagnent beaucoup de temps, de malentendus et de rancune de cette façon. Le fait qu’il y ait de nombreux commentaires sur le code indique qu’il y a probablement un malentendu de part et d’autre. Ces types de malentendus sont plus faciles à identifier et à résoudre en parlant des choses.
Nitpicks
Les nitpicks sont des commentaires sans importance, où le code pourrait être fusionné sans même les aborder. Il peut s’agir de choses comme des déclarations de variables dans l’ordre alphabétique, des tests unitaires suivant une certaine structure, ou des parenthèses sur la même ligne.
Les bonnes revues de code indiquent clairement quand les changements sont des pinaillages sans importance. Elles marquent généralement les commentaires de ce type de manière distincte, en leur ajoutant le préfixe « nit : ». Un trop grand nombre de ces commentaires peut devenir frustrant et détourner l’attention des parties les plus importantes de la revue, donc les réviseurs visent à ne pas en abuser.
Les meilleures revues de code réalisent que trop de pinaillages sont le signe d’un manque d’outils ou d’un manque de normes. Les réviseurs qui les rencontrent fréquemment chercheront à résoudre ce problème en dehors du processus de revue de code. Par exemple, un grand nombre des commentaires les plus fréquents peuvent être résolus grâce à un linting automatisé. Ceux qui ne le peuvent pas peuvent généralement être résolus par l’équipe qui accepte certaines normes et les suit – peut-être même en les automatisant, à terme.
Les revues de code pour les nouveaux arrivants
Débuter dans une nouvelle entreprise est accablant pour la plupart des gens. La base de code est nouvelle, le style de programmation est différent de celui d’avant, et les gens examinent votre code très différemment. Alors, les revues de code doivent-elles être plus douces pour les nouveaux arrivants, afin de les habituer au nouvel environnement, ou doivent-elles maintenir la barre aussi haute, comme pour tout le monde ?
Les bonnes revues de code utilisent la même barre de qualité et la même approche pour tout le monde, indépendamment de leur titre de poste, de leur niveau ou du moment où ils ont rejoint l’entreprise. À la suite de ce qui précède, les revues de code ont un ton aimable, demandent des modifications lorsque cela est nécessaire, et vont chercher à parler aux réviseurs lorsqu’ils ont beaucoup de commentaires.
Les meilleures revues de code accordent une attention supplémentaire pour que les premières revues des nouveaux arrivants soient une bonne expérience. Les réviseurs sont empathiques au fait que le nouvel adhérent peut ne pas connaître toutes les directives de codage et peut ne pas être familier avec certaines parties du code. Ces critiques s’efforcent d’expliquer les approches alternatives et de pointer vers des guides. Elles ont également un ton très positif, célébrant les premières modifications de la base de code que l’auteur suggère.
Revues inter-bureaux, inter-zones temporelles
Les revues de code deviennent plus difficiles lorsque les réviseurs ne se trouvent pas au même endroit. Ils sont particulièrement difficiles lorsque les examinateurs sont assis dans des fuseaux horaires très différents. J’ai eu ma juste part de ces revues au fil des ans, modifiant du code appartenant à des équipes aux États-Unis et en Asie, tout en étant basé en Europe.
Les bonnes revues de code tiennent compte du décalage horaire quand elles le peuvent. Les réviseurs visent à réviser le code dans les heures de travail qui se chevauchent entre les bureaux. Pour les revues comportant de nombreux commentaires, les réviseurs proposeront de chatter directement ou de faire un appel vidéo pour discuter des changements.
Les meilleures revues de code remarquent lorsque les revues de code se heurtent de manière répétée à des problèmes de fuseau horaire et cherchent une solution systémique, en dehors du cadre de la revue de code. Disons qu’une équipe d’Europe modifie fréquemment un service qui déclenche des revues de code de la part du propriétaire de ce service basé aux États-Unis. La question au niveau du système est de savoir pourquoi ces changements sont si fréquents. Les changements sont-ils effectués dans la bonne base de code ou un autre système devrait-il être modifié ? La fréquence des changements sera-t-elle la même ou diminuera-t-elle avec le temps ? En supposant que les changements sont effectués dans la bonne base de code et que la fréquence ne diminuera pas, la dépendance entre les bureaux peut-elle être brisée d’une manière ou d’une autre ? Les solutions à ce type de problèmes ne sont souvent pas simples et peuvent impliquer une refonte, la création de nouveaux services/interfaces ou l’amélioration des outils. Mais la résolution de dépendances de ce type rendra la vie des deux équipes plus facile et leur progression plus efficace à long terme, ce qui signifie que le retour sur investissement est souvent assez impressionnant.
Soutien organisationnel
La façon dont les entreprises et leurs organisations d’ingénierie abordent les revues de code est un élément important de leur efficacité. Les organisations qui les considèrent comme peu importantes et triviales finissent par investir peu dans la facilitation des revues. Dans de telles cultures, il peut être tentant d’éliminer complètement les revues de code. Les ingénieurs qui plaident pour de meilleures revues de code peuvent se sentir isolés, sans soutien de la part de leurs supérieurs et finir par abandonner. Le résultat est une organisation où les problèmes continuent de se répéter et de s’accumuler.
Les organisations avec de bonnes revues de code s’assurent que tous les ingénieurs prennent part au processus de revue de code – même ceux qui pourraient travailler sur des projets solo. Elles encouragent l’élévation de la barre de qualité, et les équipes facilitent des discussions saines sur les approches de revue de code, tant au niveau de l’équipe que de l’org. Ces entreprises ont souvent des guides de revue de code pour les bases de code plus importantes que les ingénieurs ont initiées et écrites. Les organisations de ce type reconnaissent que les revues de code prennent une bonne partie du temps des ingénieurs. Beaucoup de ces entreprises ajouteront les revues de code comme attentes aux compétences professionnelles des développeurs, s’attendant à ce que les ingénieurs seniors passent une plus grande partie de leur temps à revoir le code des autres.
Les organisations avec de meilleures revues de code ont des règles strictes autour d’aucun code ne se rendant à la production sans une revue de code – tout comme les changements de logique métier ne se rendent pas à la production sans tests automatisés. Ces organisations ont appris que le coût de la réduction des coûts n’en vaut pas la peine ; au lieu de cela, elles ont des processus pour des revues accélérées pour les cas urgents. Ces organisations investissent dans la productivité des développeurs, notamment en travaillant continuellement à l’élaboration de revues de code plus efficaces et à l’amélioration des outils. Les responsables de l’ingénierie n’ont pas besoin d’être convaincus des avantages des revues de code et des autres meilleures pratiques d’ingénierie. Au lieu de cela, ils soutiennent les initiatives sur l’amélioration des outils ou les processus de revue de code plus efficaces qui proviennent des équipes.
Lorsque les gens rencontrent des revues qui leur semblent hostiles, ils sentent qu’ils peuvent s’exprimer et bénéficier d’un soutien tous azimuts pour résoudre le problème. Les ingénieurs et les managers seniors considèrent que les revues de code qui ne sont pas à la hauteur sont tout autant un problème que le code bâclé ou le mauvais comportement. Les ingénieurs et les responsables de l’ingénierie se sentent habilités à améliorer la façon dont les revues de code sont effectuées.
Débuter avec du bon, améliorer
Les bonnes revues de code comportent déjà beaucoup de bons efforts. Ils font un examen approfondi de la modification elle-même, évitent d’avoir un avis sur le ton des commentaires, et rendent les pinaillages clairs. Elles maintiennent une barre cohérente, indépendamment de la personne qui demande la révision et essaient de rendre les révisions inter-fuseaux horaires moins pénibles en y prêtant une attention supplémentaire. Les organisations qui ont de bonnes revues s’assurent que chaque développeur reçoit et effectue régulièrement des revues de code. La barre est déjà haute, mais si vous y arrivez, ne vous arrêtez pas. Les revues de code sont l’un des meilleurs moyens d’améliorer vos compétences, d’encadrer les autres et d’apprendre à devenir un communicateur plus efficace.
Gardez de meilleures revues de code en vous améliorant continuellement sur les détails, mais commencez aussi à regarder les changements à un haut niveau également. Soyez empathique dans le ton des commentaires et pensez à des moyens en dehors du processus de revue de code pour éliminer les pinaillages fréquents. Rendez les revues de code particulièrement accueillantes pour les nouveaux arrivants et recherchez des solutions systémiques pour les revues pénibles dans les différents fuseaux horaires. Les organisations tournées vers l’avenir encouragent l’investissement dans l’amélioration des outils et des processus afin de rendre les revues de code plus performantes, en récoltant davantage de bénéfices.
—
Gergely est actuellement un chef d’ingénierie à Amsterdam. Ce billet de blog a été initialement publié sur le blog de Gergely, The Pragmatic Engineer. Si vous souhaitez lire d’autres articles de Gergely, vous pouvez vous abonner à sa newsletter mensuelle pour lire ses articles sur l’ingénierie, le leadership technologique et les systèmes distribués. Si vous souhaitez contribuer aux articles du blog Stack Overflow, envoyez un courriel à [email protected].
Tags : bulletin, revue de code, ingénierie, développement logiciel.