Catégories
Start-up et applications

L'art des révisions de code

Les revues de code sont un élément crucial du processus de développement logiciel. Il encourage l'équipe de développement logiciel à interagir les unes avec les autres, à collaborer et à améliorer la qualité de leur code. Cependant, il ne suffit pas de vérifier le nouveau code pour détecter les erreurs et se familiariser avec la base de code.

Selon Phil Hughes, ingénieur front-end chez GitLab, il s'agit de la façon dont vous fournissez et transmettez ces commentaires – et c'est une forme d'art et une compétence qui s'acquièrent au fil du temps. «Réviser efficacement le code est une compétence qui s'apprend au fur et à mesure que vous le faites. Passer du temps à créer un flux de travail qui fonctionne pour vous est tout aussi important », a-t-il écrit dans un article de blog.

Voici quelques conseils et astuces pour perfectionner votre processus de révision de code et aider les équipes à s'engager sur la bonne voie:

Décidez de la manière dont vous souhaitez effectuer les révisions de code: Selon Sandya Sankarram, ingénieur logiciel chez SurveyMonkey, il existe trois façons de procéder à une révision du code: 1. Procédures de groupe où le code est examiné en groupe en personne. Les avantages de ceci sont la possibilité de débattre des préoccupations et des commentaires en temps réel. 2. Programmation en binôme où deux développeurs travaillent ensemble, l'un écrivant le code et l'autre observant et offrant des conseils en cours de route. 3. Tirez les révisions de code de demande où les révisions de code se produisent hors ligne; des critiques, des modifications et des commentaires peuvent être ajoutés ligne par ligne, et des commentaires peuvent être donnés via des commits.

«C’est comme si un correcteur examinait ce que vous écrivez et, espérons-le, il verra quelque chose que vous ne voyez pas. Parfois, il s'agit pour les réviseurs d'avoir plus d'expertise sur le fichier particulier et un référentiel particulier afin qu'ils puissent vous donner un contexte supplémentaire sur ce que vous pourriez changer ou identifier un problème potentiel », a déclaré Jarred Colli, responsable produit pour Bitbucket chez Atlassian.

Gérez efficacement le temps: L’un des principaux défis des révisions de code est de s’assurer que les développeurs allouent suffisamment de temps pour examiner le code de chacun. "Il n'est pas rare que quelqu'un soumette une demande de tirage et attende deux semaines que ses coéquipiers leur donnent des commentaires avant de pouvoir fusionner", a déclaré Colli. «En fin de compte, l'objectif des équipes de développement est de fusionner rapidement du code de haute qualité. Certaines personnes ont tort de s'assurer que le code est de haute qualité. Certaines personnes préfèrent se tromper en s'assurant que c'est fait rapidement. Le but est d'essayer de faire les deux. »

Une façon de faire les deux est de s'assurer que le code ne reste pas non fusionné pendant de longues périodes. Selon Colli, moins il reste non fusionné, moins il a d'opportunités de changer ou de causer des problèmes potentiels. Les demandes d'extraction ajoutées par Colli doivent être examinées par les coéquipiers dans quelques jours, puis fusionnées.

Selon Hughes de GitLab, les développeurs individuels devraient trouver dans leur routine quotidienne un moment qui leur convient le mieux. Par exemple, il constate que commencer sa journée avec des révisions de code lui procure moins de distractions et plus de productivité. De plus, Hughes dit avoir un accord sur la durée des révisions de code. GitLab a un objectif de niveau de service de 2 jours pour que les réviseurs obtiennent des commentaires aux développeurs.

Soyez bref et simple: Il y a une tendance à rassembler toutes les modifications dans un seul grand paquet, puis à le rendre accessible à tous. Cela rend le processus déroutant car plusieurs fichiers peuvent changer simultanément, ce qui rend difficile la révision efficace du code. Cela réduit également la probabilité que les membres de l'équipe découvrent des problèmes. «Les développeurs sont tellement occupés par un million de choses différentes qu'il est difficile de s'asseoir et de tout faire en même temps. Ils finissent par devoir revenir plusieurs fois sur la revue, ils risquent de sauter un fichier, de perdre leur place ou d'oublier ce qu'ils ont lu auparavant », a déclaré Colli.

Le resserrement de la boucle de rétroaction entre l'écriture du code et l'obtention de commentaires empêche également les développeurs de devenir trop attachés au code, puis de se mettre sur la défensive face aux modifications qui y sont apportées, selon Erik Dietrich, programmeur et co-fondateur de la société de marketing de contenu technique Hit Souscrire. La programmation par paires fonctionne bien ici car les développeurs sont étroitement alignés, de sorte que lorsqu'ils font une erreur, ils peuvent immédiatement obtenir ce retour.

Automatisez si possible: Selon Aki Asahara, PDG de la société de développement de logiciels Sleeek, environ 30% ou plus du temps de travail d'une équipe est constitué de révisions de code. En étant capable d'automatiser certaines parties de la révision du code, il peut gagner du temps et activer un code de meilleure qualité. Asahara a expliqué que la majorité des révisions de code impliquent simplement de vérifier l'état et le style du code. Grâce à un outil automatisé, les équipes peuvent rédiger des politiques ou des règles personnalisées afin que les développeurs n'aient pas à se soucier de la vérification orthographique ou des tâches répétitives, et puissent gérer des parties plus essentielles du code.

Atlassian's Colli a expliqué qu'il existe de nombreux autres outils automatisés pour aider à prendre en charge et réduire le temps nécessaire pour effectuer une révision du code. Les outils d'analyse du code peuvent aider à identifier les dépendances et les problèmes pour informer les développeurs si des éléments doivent être mis à jour et fournir plus de contexte autour du code en cours de modification. Les outils d'analyse de sécurité peuvent aider à détecter les vulnérabilités potentielles.

Selon Dietrich, disposer d'outils automatisés réduit également la pression et les conflits sur les développeurs et les coéquipiers. Il a expliqué que les développeurs ont tendance à avoir des connotations négatives envers les critiques parce qu'ils ont l'impression de prendre trop de temps ou de pinailler leur code. «Et au-delà de la dynamique interpersonnelle, les revues automatisées sont relativement infaillibles. (Les outils automatisés) ne manqueront pas quelque chose parce qu’ils n’ont pas encore pris leur café ou parce qu’ils y sont depuis des heures, c’est vendredi et ils veulent passer la journée », a déclaré Dietrich.

Ayez une liste de contrôle: Atlassian's Colli a expliqué qu'il peut être difficile pour les coéquipiers de confirmer que les évaluations ont été effectuées et que les suggestions et les commentaires ont été correctement appliqués. Une liste de contrôle pourrait indiquer si le code a examiné les commentaires ou non; quelque chose a été fait à ce sujet; a-t-il été fait de la manière suggérée, pourquoi ou pourquoi pas?

Profitez des contrôles de fusion ou des restrictions de succursale: À l'instar des stratégies personnalisées, les vérifications de fusion ou les restrictions de branche peuvent définir des règles conditionnelles en place avant qu'une demande d'extraction ne puisse être fusionnée. «Plus vous pouvez ajouter de structure aux allers-retours entre les coéquipiers fournissant des commentaires, mieux vous serez», a déclaré Colli. Par exemple, une vérification peut consister à s'assurer que le code a été vérifié et approuvé par au moins deux réviseurs avant de pouvoir passer à autre chose; ou si une faille de sécurité est identifiée par l'outil d'analyse de sécurité, le code ne sera pas fusionné.

Profitez du talent: Une stratégie consiste à trouver des développeurs qui comprennent la complexité du code ou qui sont des experts dans le domaine du code en cours de vérification afin qu'ils puissent fournir des commentaires sur tout changement à risque, selon Colli.

Utilisez les revues de code comme une opportunité d'enseignement: Les réviseurs de code aident les développeurs à se familiariser avec la base de code, mais c'est aussi l'occasion pour les développeurs expérimentés d'aider les développeurs juniors en leur expliquant comment ils auraient pu être plus efficaces. «Peu de gens réalisent l'impact sur le partage des connaissances et les revues de code de mentorat sur une équipe. Ils sont un outil pour aider les ingénieurs à se développer plus rapidement (les ingénieurs juniors voient le code des seniors plus fréquemment), à améliorer leur mentorat (en donnant des commentaires constructifs) », a écrit Gergely Orosz, responsable de l'ingénierie chez Uber, dans un e-mail à SD Times.

Sans revues de code, le processus de développement logiciel peut souffrir de «moins de partage de connaissances, d'erreurs plus facilement évitables en production» et d'un code «souvent moins lisible en conséquence», a-t-il expliqué.

Des révisions de code insignifiantes aux critiques
Les révisions de code peuvent être une source d'anxiété et de misère pour les groupes qui sont plus sensibles et apprécient une rétroaction polie et douce. Mais d'un autre côté, les révisions de code peuvent également être idéales pour les groupes de personnes qui apprécient les commentaires directs et honnêtes, aussi directs ou brutaux soient-ils. «Pour ce dernier groupe, la révision du code est excellente; c'est une chance de s'affronter sur des croyances personnelles fermement ancrées sans (théoriquement, dans leur esprit) aucun rancune », a déclaré Dietrich.

Cela n’a pas à être d’une manière ou d’une autre. Selon Sankarram, il existe un juste milieu.

Dans une conférence sur «Désapprendre les comportements toxiques dans une culture de révision de code», Sankarram a souligné certains comportements toxiques qu'elle et d'autres ont expérimentés et a formulé des recommandations pour améliorer la culture de révision de code.

"N'oubliez pas que je ne décourage pas les commentaires. Je fais juste un plaidoyer pour que les gens gouvernent leur ton et la façon dont ils choisissent de fournir le contenu de leurs commentaires », a-t-elle déclaré dans son discours.

Ne faites pas passer votre opinion comme un fait: À moins que vous ne puissiez fournir les ressources et la documentation appropriées pour étayer votre réclamation. Selon Sankarram, cela est courant lorsqu'il s'agit de style et de syntaxe. Elle a recommandé de mettre en œuvre un linter ou un correctif de code automatique afin que les membres de l'équipe puissent voir les règles de style à suivre. «Vous devriez encourager les débats et ne pas faire de demandes», a déclaré Sankarram.

Dietrich a expliqué que «c'est faux» ou «c'est mauvais» peut amener les développeurs à se montrer défensifs. «Comparez cela avec une déclaration comme« ce n’est pas ce que j’aurais fait là-bas »», qui est essentiellement incontestable. Mieux encore, j’ai trouvé, c’est de poser des questions à la place, comme «pourquoi avez-vous choisi cette mise en œuvre» ou «cela ne pourrait-il pas conduire à une condition de concurrence?», At-il ajouté.

Utiliser des opinions plutôt que des faits peut également faire perdre du temps aux développeurs à se disputer sur des préoccupations subjectives. "Si vous avez des évaluateurs dominateurs qui fournissent des commentaires qui sont totalement inopérants ou arbitraires, cela crée une impuissance acquise chez les sujets de cet examen. Ils apprennent à faire un effort assez minime, car la personnalité dominatrice va de toute façon séparer tout ce qu'ils font », a déclaré Dietrich.

Ne laissez pas une quantité écrasante de commentaires: «Lorsqu'une personne fait une erreur, il y a de fortes chances qu'elle ait commis la même erreur à plusieurs endroits», a expliqué Sankarram. Au lieu de laisser des commentaires à chaque endroit où l'erreur s'est produite, laissez simplement des notes détaillées avec des liens et des ressources utiles afin que vous transmettiez votre message, mais ne submergez pas le développeur.

Ne demandez pas aux réviseurs de résoudre les problèmes: S'il y a des problèmes dans le code qui ne sont pas directement liés à la modification du réviseur, cela devient une discussion distincte.

Ne posez pas de questions de jugement: Cela ne sert à rien et implique que le développeur aurait dû connaître une solution simple. Cela oblige également le développeur à défendre son travail. Au lieu de cela, vous pourriez leur recommander de le faire d'une manière différente plutôt que d'utiliser des mots durs et critiques tels que "Pourquoi ne l'avez-vous pas fait de cette façon?" m'a dit Sankarram.

Ne soyez pas sarcastique: Les révisions de code ne sont pas le moment d'être sarcastique, c'est le moment d'offrir des commentaires à quelqu'un. "Dire quelque chose comme" Avez-vous même testé ce code avant de l’enregistrer? "Est sarcastique, impoli et ne donne pas de contexte ni de commentaires exploitables. Il vaut mieux décrire le problème et ne pas perdre de temps », Expliqua Sankarram.

N'utilisez pas d'émojis pour exprimer des sentiments ou signaler des problèmes: Par exemple, Sankarram a vu les emoji de pouce vers le bas ou de vomissement utilisés dans les révisions de code précédentes. Les émojis, bien qu'amusants, sont cryptiques et faciles à mal comprendre et font perdre du temps aux gens à essayer de comprendre ce que signifie l'émoji.

Ne fantômes pas les gens: Les développeurs qui recherchent des révisions de code peuvent également contribuer à la culture toxique en ne répondant pas aux commentaires, laissant les gens se demander pourquoi ils ont même pris la peine de vous aider en premier lieu. Si vous n'êtes pas d'accord avec quelque chose ou si vous ne comptez pas apporter de modification en particulier, indiquez pourquoi au réviseur.

N'ignorez pas les comportements toxiques: Selon Sankarram, il est courant de désaccentuer le comportement, surtout s'il provient d'un développeur très performant ou productif, mais ces développeurs doivent tout de même comprendre que leurs comportements sont stressants et épuisant et ne sont pas utiles aux autres membres de l'équipe. «Les enjeux sont assez élevés, ne pas prendre de mesures pour désapprendre ces comportements toxiques a de sérieux revers pour l'équipe, car les développeurs se sentent dépassés, attaqués et démotivés. Ils commencent à rédiger ces processus de rétroaction censés les aider à grandir », a déclaré Sankarram.

Dietrich a également suggéré que les révisions de code devraient être bidirectionnelles et inclure tous les membres de l'équipe, quel que soit leur niveau d'expérience. En outre, laisser les membres de l'équipe choisir leurs propres réviseurs de code peut les aider à être plus à l'aise avec la révision.

«Vous voulez vous assurer que les gens se sentent en sécurité pour prendre des risques et obtenir des commentaires, et ne pas avoir peur d'avoir des commentaires négatifs ou d'essayer quelque chose de différent. Chaque équipe doit commencer par trouver comment créer cet environnement de confiance avec d’autres collaborateurs afin que ce genre de problèmes se dissipe à travers tout le travail que vous faites ensemble », a ajouté M. Colli d’Atlassian.

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *