Apporter à votre équipe une mentalité de révision du code de la santé

Une «révision du code» est un moment du processus de développement dans lequel vous (19459023) (en tant que développeur) et vos collègues travaillez. ensemble et recherchez les bogues dans un morceau de code récent avant sa publication. Dans un tel moment, vous pouvez être l'auteur du code ou l'un des réviseurs.

Lors de la révision du code, il est possible que vous ne soyez pas sûr de ce que vous recherchez. De l'autre côté, lors de la soumission d'une révision de code, vous pourriez ne pas savoir quoi attendre. Ce manque d'empathie et de fausses attentes entre les deux parties peut déclencher des situations déplorables et accélérer le processus jusqu'à aboutir à une expérience désagréable pour les deux parties.

Dans cet article, je vais vous expliquer en quoi ce résultat peut être modifié d'ici à . ] changer votre état d'esprit lors d'une révision du code:

Travailler en équipe

Favoriser une culture de collaboration

Avant de commencer, il est fondamental de comprendre la valeur de pourquoi le code doit être révisé . Le partage des connaissances et la cohésion des équipes profitent à tout le monde. Toutefois, s’ils adoptent un état d’esprit médiocre, une révision de code peut être un très gros consommateur de temps avec des résultats désagréables.

L’attitude et le comportement de l’équipe devraient reconnaître la valeur d’une collaboration non critique, l'objectif commun d'apprendre et de partager – quelle que soit l'expérience de quelqu'un d'autre

Inclure les révisions de code dans vos estimations

Une révision complète du code prend du temps. Si un changement a pris une semaine, ne vous attendez pas à ce que la révision du code prenne moins d’une journée. Cela ne fonctionne tout simplement pas comme ça. N'essayez pas de lancer une révision de code à la hâte, ni de la considérer comme un goulot d'étranglement.

La révision de code est aussi importante que la rédaction du code lui-même. En tant qu'équipe, n'oubliez pas de inclure des révisions de code dans votre flux de travail et de définir les attentes quant à la durée d'une révision de code, afin que tout le monde soit synchronisé et confiant dans son travail.

Gagnez du temps en utilisant des instructions et l'automatisation [19659009] Un moyen efficace de garantir des contributions cohérentes consiste à intégrer un modèle Pull Request au projet. Cela aidera l'auteur à soumettre un RP en bonne santé avec une description complète. Une description de relations publiques doit expliquer quel est le but du changement, sa raison et comment le reproduire. Les captures d'écran et les liens de référence (problème Git, fichier de conception, etc.) constituent la dernière touche à une soumission qui se passe d'explication.

Si vous faites tout cela, cela empêchera les examinateurs de faire les premiers commentaires en leur demandant plus de détails. Une autre façon de rendre les révisions de code moins banales consiste à utiliser linters pour résoudre les problèmes de formatage et de qualité du code avant même que le réviseur ne soit impliqué. Chaque fois que vous voyez un commentaire répétitif pendant le processus de révision, cherchez des moyens de le minimiser (en utilisant de meilleures directives ou une automatisation de code plus efficace).

Restez étudiant

N'importe qui peut effectuer une révision de code et tout le monde doit recevoir une révision de code. – peu importe le niveau d'ancienneté. Recevez toute rétroaction avec gratitude comme une occasion d'apprendre et de partager des connaissances. Considérez n'importe quel retour comme une discussion ouverte plutôt que comme une réaction défensive. L'amateur est défensif. Le professionnel trouve qu'il est agréable d'apprendre. Restez humble car dès que vous cessez d'être un étudiant, vos connaissances deviennent fragiles.

L'art de sélectionner des réviseurs

À mon avis, choisir les réviseurs est l'une des décisions les plus importantes à prendre en compte pour une révision du code efficace et saine. équipe.

Supposons que votre collègue soumette une révision de code et décide de balayer «tout le monde» car, inconsciemment, il pourrait vouloir accélérer le processus, fournir le meilleur code possible ou s’assurer que tout le monde est au courant du changement de code. . Chacun des relecteurs reçoit une notification, puis ouvre le lien PR et voit un grand nombre de personnes étiquetées comme relecteurs. La pensée de «quelqu'un d'autre le fera» leur vient à l'esprit, ce qui conduit à ignorer la révision du code et à fermer le lien.

Comme personne n'a encore lancé la révision, votre collègue rappellera à chacun des réviseurs de le faire, c'est à dire créer une pression sur eux. Une fois que les réviseurs ont commencé à le faire, le processus de révision prend une éternité, car chacun a sa propre opinion et c’est un cauchemar de parvenir à un accord. Entre-temps, la personne qui a décidé de ne pas réviser le code est par la suite spammée de zillions de notifications par courrier électronique avec tous les commentaires de révision, créant ainsi un bruit dans leur productivité.

C'est quelque chose que je vois se produire plus que je ne le souhaiterais: Tirer des demandes avec un groupe de personnes étiquetées comme relecteurs et se terminant, ironiquement, par une révision de code non productive.

La sélection des relecteurs présente certains flux efficaces: Un flux possible consiste à choisir deux ou trois collègues qui sont familiers. avec le code et leur demander d'être des critiques. Une autre approche, expliquée par l’équipe Gitlab, consiste à créer un flux d’examens chaînés dans lequel l’auteur choisit un relecteur qui en sélectionne un autre jusqu’à ce qu’au moins deux relecteurs soient d’accord avec le code. Quel que soit le flux que vous choisissez, évite d'avoir trop de relecteurs . Pouvoir faire confiance au jugement de vos collègues en matière de code est la clé d’une révision efficace et saine du code.

Have Empathy

La découverte de codes à améliorer n’est qu’une partie de la réussite de la révision du code. Il est tout aussi important de communiquer ces informations de manière saine en faisant preuve d’empathie envers vos collègues.

Avant d’écrire un commentaire, n'oubliez pas de vous mettre à la place des autres. Il est facile d’être mal compris en écrivant. Révisez donc vos propres mots avant de les envoyer. Même si une conversation commence à être laide, ne la laissez pas vous toucher, restez toujours respectueuse. Bien parler aux autres n’est jamais une mauvaise décision.

Comprendre le compromis

Si une discussion n’est pas résolue rapidement, dirigez-la vers un appel personnel ou une discussion en ligne. Analysez ensemble s’il s’agit d’un sujet qui mérite d’être paralysé par la demande de modification actuelle ou qui peut être traité dans une autre.

Soyez souple mais pragmatique et sachez trouver le juste équilibre entre efficacité (efficacité) et efficacité (qualité). C’est un compromis à faire en équipe. Dans ces moments, j'aime penser à une révision de code comme une itération plutôt qu'une solution finale.

Révisions de codes en personne

Rassembler l’auteur et le critique dans un style de programmation par paires peut s'avérer très efficace. Personnellement, je préfère cette approche lorsque la révision du code implique des changements complexes ou qu’il est possible de partager beaucoup de connaissances. Bien qu’il s’agisse d’une révision de code hors ligne, c’est une bonne habitude de laisser des commentaires en ligne sur les discussions engagées, en particulier lorsque des modifications doivent être apportées après la réunion. Cela est également utile pour tenir les autres réviseurs en ligne au courant.

Apprenez des résultats de la révision du code

Quand une révision du code subit de nombreux changements, prend trop de temps ou a déjà trop discuté, rassemblez votre équipe et analyser les causes et les actions qui peuvent en être prises. Lorsque la révision de code est complexe, diviser une tâche future en tâches plus petites facilite chaque révision de code.

Lorsque l'écart d'expérience est grand, l'adoption de la programmation en binôme est une stratégie aux résultats incroyables, pas seulement pour le savoir. partage mais aussi pour la collaboration et la communication hors ligne. Quel que soit le résultat, visez toujours une équipe dynamique et saine avec des attentes claires.

? En tant qu'auteur

L'une des principales préoccupations lorsque vous travaillez sur une révision de code en tant qu'auteur est de minimiser la surprise de celui-ci lorsque vous lisez le code. la première fois. C’est la première étape d’une révision prévisible et sans heurts du code. Voici comment vous pouvez le faire.

Établir une communication précoce

Ce n’est jamais une mauvaise idée de parler à vos futurs réviseurs avant de trop coder. Chaque fois qu’il s’agit d’une contribution interne ou externe, vous pouvez faire un raffinement ensemble ou un peu de programmation en binôme au début du développement pour discuter des solutions.

Il n’ya rien de mal à demander de l’aide dans un premier temps. En fait, travailler ensemble en dehors de l'examen est une première étape importante pour prévenir les erreurs précoces et garantir un accord initial. En même temps, vos réviseurs sont informés de la prochaine révision du code.

Suivez les instructions

Lorsque vous soumettez une demande d'extraction à examiner, n'oubliez pas d'ajouter une description et de suivre les instructions. Cela évitera aux examinateurs de perdre du temps à comprendre le contexte du nouveau code. Même si vos réviseurs savent déjà de quoi il s'agit, vous pouvez également saisir cette occasion pour améliorer vos compétences en écriture et en communication.

Soyez votre premier critique

Voir votre propre code dans un contexte différent vous permet de le trouver. choses que vous manqueriez dans votre éditeur de code. Révisez le code de votre propre code avant de demander à vos collègues. Ayez une mentalité de critique et parcourez vraiment chaque ligne de code.

Personnellement, J'aime annoter mes propres critiques de code pour mieux guider mes critiques. L'objectif ici est d'éviter les commentaires liés à un éventuel manque d'attention et de vous assurer que vous avez suivi les directives de contribution. Essayez de soumettre une révision de code comme vous souhaiteriez en recevoir une.

Soyez patient

Après avoir soumis une révision de code, ne sautez pas directement dans un nouveau message privé demandant à vos réviseurs de «jeter un coup d'œil, il ne prend quelques minutes »et indirectement en manque d’émoji. Essayer de pousser vos collègues à faire leur travail n’est pas un état d’esprit sain. Au lieu de cela, fait confiance au flux de travail de vos collègues comme ils vous font confiance pour soumettre une bonne révision de code. En attendant, attendez qu'ils reviennent vers vous lorsqu'ils seront disponibles. Ne considérez pas vos relecteurs comme un goulot d’étranglement. N'oubliez pas d'être patient car les choses difficiles prennent du temps.

Soyez un auditeur

Une fois l'examen du code soumis, des commentaires seront fournis, des questions seront posées et des modifications proposées. La règle d'or est de ne prendre aucune réaction comme une attaque personnelle. N'oubliez pas que n'importe quel code peut bénéficier d'une perspective extérieure .

Ne considérez pas vos relecteurs comme des ennemis. Au lieu de cela, prenez ce moment pour mettre de côté votre ego, acceptez de faire des erreurs et soyez ouvert à apprendre de vos collègues, afin de pouvoir faire un meilleur travail la prochaine fois.

? En tant que critique

De votre temps

Quand on vous demande de faire la critique, n'interrompez pas les choses tout de suite. C’est une erreur commune que je vois tout le temps. La révision du code requiert toute votre attention et chaque fois que vous changez de contexte, vous réduisez votre productivité en perdant du temps à recalibrer votre focus. Au lieu de cela, planifiez à l'avance en allouant des créneaux horaires de votre journée pour procéder à la révision du code.

Personnellement, je préfère procéder à la révision du code le lendemain matin ou après le déjeuner avant de choisir une autre de mes tâches. C’est ce qui fonctionne le mieux pour moi car mon cerveau est encore frais sans qu’un contexte de code précédent ne soit désactivé. De plus, une fois la révision terminée, je peux me concentrer sur mes propres tâches, tandis que l'auteur peut réévaluer le code en fonction des commentaires.

Soyez solidaire

Quand une demande d'extraction ne suit pas la contribution directives, apportez votre soutien, en particulier aux nouveaux arrivants. Profitez de ce moment pour guider l’auteur dans l’amélioration de sa contribution. En attendant, essayez de comprendre pourquoi l’auteur n’a pas suivi les directives. Il y a peut-être place à des améliorations dont vous n'aviez pas connaissance auparavant.

Vérification de la branche exécutée

Lorsque vous examinez le code, faites-le fonctionner sur votre propre ordinateur, en particulier lorsqu'il implique l'utilisateur. interfaces. Cette habitude vous aidera à mieux comprendre le nouveau code et à repérer tout ce qui pourrait vous échapper si vous utilisiez simplement un outil de diff par défaut dans le navigateur, ce qui limite la portée de votre révision au code modifié (sans avoir le contexte complet comme dans votre éditeur de code). .

Demandez avant d’assumer

Si vous ne comprenez pas quelque chose, n’ayez pas peur de le dire et de poser des questions. Quand vous posez la question, n'oubliez pas de lire d'abord le code environnant et d'éviter de faire des suppositions.

La plupart des questions relèvent de ces deux catégories:

1. «Comment» Questions
   Quand vous ne comprenez pas comment quelque chose fonctionne ou ce qu’il fait, évalue avec l’auteur si le code est suffisamment clair. Ne confondez pas le code simple avec l’ignorance. Il existe une différence entre un code difficile à lire et un code que vous ne connaissez pas. Soyez ouvert pour apprendre et utiliser une nouvelle fonctionnalité linguistique, même si vous ne la connaissez pas encore profondément. Cependant, ne l'utilisez que si cela simplifie la base de code.
2. Questions sur le pourquoi (1965)
   Si vous ne comprenez pas le "pourquoi", n'ayez pas peur de suggérer de commenter le code, surtout si c'est un cas de bord ou un correctif . Le code doit être explicite lorsqu'il s'agit d'expliquer ce qu'il fait. Les commentaires sont un complément pour expliquer le pourquoi derrière une certaine approche. Expliquer le contexte est très précieux en termes de maintenabilité et cela évitera à quelqu'un de de supprimer un bloc de code que la pensée était inutile . (Personnellement, j'aime commenter le code jusqu'à ce que je sois sûr de l'oublier plus tard.)

Critique constructive

Une fois que vous avez trouvé un élément de code que vous estimez devoir être amélioré, souvenez-vous toujours de reconnaître les efforts de l'auteur. contribuez au projet et exprimez-vous de manière ouverte et transparente

• Discussions ouvertes
  Évitez de formaliser vos commentaires sous forme de commandement ou d'accusation du type «Vous devriez…» ou «Vous avez oublié…». Exprimez vos commentaires sous forme de discussion ouverte au lieu de demande obligatoire. N'oubliez pas de commenter le code, pas l'auteur. Si le commentaire ne concerne pas le code, il ne doit pas appartenir à une révision de code. Comme dit précédemment, soyez favorable. Utiliser une voix passive, parler au pluriel, exprimer des questions ou des suggestions sont de bonnes méthodes pour insister sur l'empathie avec l'auteur.

Au lieu de “Extraire cette méthode à partir d'ici…”, préférez “Cette méthode doit être extraite…” ou “Que faites-vous? vous pensez extraire cette méthode… »

• Soyez clair.
  Un feedback peut facilement être mal interprété, en particulier lorsqu'il s'agit d'exprimer une opinion par opposition à un partage d'un fait ou d'une directive. N'oubliez jamais de clarifier cela tout de suite dans votre commentaire.

Peu clair: «Ce code devrait être…»

Opinion: «Je crois que ce code devrait être…»

Fait: «Après [our guidelines]ce le code devrait être… ».

• Expliquez pourquoi.
  Ce qui est évident pour vous, peut ne pas l'être pour d'autres. Il n’explique jamais trop la motivation de vos commentaires et l’auteur comprend non seulement comment changer quelque chose, mais aussi quel en est l’avantage.

Opinion: “Je crois que ce code pourrait être…”

Explained: “I crois que ce code pourrait être (…) car cela améliorera la lisibilité et simplifiera les tests unitaires. "

• Donnez des exemples.
  Lorsque vous partagez une fonction de code ou un modèle inconnu de l'auteur, complétez votre suggestion avec une référence à titre indicatif. Dans la mesure du possible, allez au-delà de la documentation MDN et partagez un extrait de code ou un exemple de travail adapté au scénario de code actuel. Quand écrire un exemple est trop complexe, soutenez-le et offrez votre aide en personne ou par appel vidéo

En plus de dire quelque chose comme «Utiliser un filtre nous aidera à [motivation]». , «Dans ce cas, cela pourrait être quelque chose comme: [snippet of code]. Vous pouvez vérifier [an example at Finder.js]. En cas de doute, n'hésitez pas à m'envoyer un message sur Slack. "

• Soyez raisonnable.
• Si la même erreur est commise à plusieurs reprises, préférez laisser un commentaire à ce sujet et rappeler à l'auteur de l'examiner à d'autres endroits, aussi. L'ajout de commentaires redondants ne fait que créer du bruit et peut être contre-productif.

Keep The Focus

Évitez de proposer des modifications de code non liées au code actuel. Avant de suggérer un changement, demandez-vous si cela est strictement nécessaire à ce moment-là. Ce type de retour est particulièrement courant chez les refacteurs. C’est l’un des nombreux compromis que nous devons faire en équipe entre efficacité et efficacité.

En ce qui concerne les refactors, personnellement, j’ai tendance à préférer d’améliorations minimes mais efficaces . Celles-ci sont plus faciles à contrôler et les risques de conflits de code lors de la mise à jour de la branche cible sont moins grandes.

Définir les attentes

Si vous laissez une révision de code à moitié terminée, informez-en l'auteur. sont sous contrôle. En fin de compte, dites également à l'auteur si vous êtes d'accord avec le nouveau code ou si vous souhaitez le réexaminer à nouveau ultérieurement.

Avant d'approuver un réexamen de code, demandez-vous si vous êtes à l'aise avec la possibilité de le toucher. ce code à l'avenir. Si oui, c’est le signe que vous avez procédé avec succès à une révision du code!

Apprendre à refuser une révision du code

Bien que personne ne l’admette, vous devez parfois refuser une révision du code. Au moment où vous décidez d'accepter une révision de code mais essayez de vous dépêcher, la qualité du projet est compromise ainsi que l'état d'esprit de votre équipe.

Lorsque vous acceptez de réviser le code d'une autre personne, cette personne fait confiance à vos capacités – c'est un engagement . Si vous n’avez pas le temps d’être critique, dites simplement non à vos collègues. Je le pense vraiment; Ne laissez pas vos collègues attendre une révision de code qui ne sera jamais effectuée. N'oubliez pas de communiquer et de garder les attentes claires . Soyez honnête avec votre équipe et mieux encore avec vous-même. Quel que soit votre choix, faites-le sainement et faites-le correctement.

Conclusion

Avec suffisamment de temps et d'expérience, procéder à la révision de codes vous apprendra beaucoup plus que de simples connaissances techniques. Vous apprendrez à donner et à recevoir les commentaires des autres, ainsi qu'à prendre des décisions plus réfléchies.

Chaque révision de code est une occasion de grandir en tant que communauté et individuellement. Même en dehors des révisions de code, n'oubliez pas de favoriser un état d'esprit sain jusqu'au jour où cela viendra naturellement à vous et à vos collègues. Parce que le partage est ce qui nous rend meilleurs!

Pour en savoir plus sur SmashingMag:

(ra, yk, il)