Révision du code – de bon à excellent


Dans l’équipe à côté de laquelle j’étais assis, un développeur junior a demandé à un senior de procéder à la révision du code d’une nouvelle fonctionnalité. Selon le processus, ce senior devait approuver toutes les modifications apportées à la production. Voici comment cela s’est passé :

Junior : « Pourriez-vous s’il vous plaît jeter un coup d’œil à mon code ?

Senior : « Non, je suis occupé. Envoyez-moi un PR ; je regarderai quand j’aurai plus de temps ». (jamais)

Junior : « C’est urgent ; notre principal client a besoin de cette solution. Pouvez-vous jeter un coup d’œil maintenant ? »

Senior (yeux qui roulent) : « O.K. »

Pendant les dix minutes suivantes, le senior faisait défiler le code dans les deux sens, ne révélant aucune émotion dans un silence de mort ; il avait l’air très malheureux. Comme le silence était insupportable et que le senior ne montrait presque aucun signe de vie, le curieux Junior interrompit le réviseur occupé en envoyant un paquet ACK. Le serveur senior a répondu :

Tsshhhhh. Je suis toujours en train de réviser. Tout craint. J’ai besoin de plus de temps. Va prendre un café.

Puis le silence est revenu. Cliquez. Cliquez. Faites défiler. Cliquer. Cliquer.

Junior, espérant apprendre quelque chose, était toujours assis à côté de Senior. L’air était tendu et sentait le trotyle. Le senior – comme un C4 – était prêt à exploser si quelqu’un bougeait ou disait un mot.


Vingt minutes se sont écoulées avant que Senior ne revienne de sa profonde transe :

Senior : « J’ai examiné attentivement votre code et c’est une merde totale.”

Junior : (⊙_⊙)

Senior : « C’est illisible et désordonné.”

Junior : (⊙_⊙)

Senior : « Et il n’est pas conforme à nos meilleures pratiques. Vous n’avez pas lu « Clean Code » ?

Junior : « Eh bien… Je… Je… Je viens de commencer à lire. »

Senior : « Vous êtes John Snow de GoF design patterns – vous ne connaissez aucun d’entre eux. »

John Snow of Patterns : « Ok, ça suffit. Pouvez-vous m’aider à améliorer le code ? »

Senior : « Désolé, mais j’ai gaspillé beaucoup de temps déjà et ont d’autres priorités. Je vais démystifier votre désordre demain entre deux réunions. Ne vous inquiétez plus de cette tâche. Prenez une tâche plus facile de la JIRA ; il y a beaucoup de tâches qui conviennent à votre niveau ».

Junior : (⊙_⊙)

Jackie Chan avec un visage de la WTF


Les gens en parlent rarement, mais dans de nombreuses entreprises, la révision du code donne aux développeurs l’impression d’être dans la merde. Dans une entreprise, je me sentais comme ça aussi, mais je n’en ai jamais parlé à personne. Parce que personne ne demande aux juniors et personne ne surveille les gardiens.

La révision du code est une forme de retour d’information extrêmement délicate : lorsque les gens mettent leur âme au travail, ils deviennent vulnérables et sensibles aux critiques. Dire que « la révision du code n’est pas pour nous, mais pour notre code » n’aide pas beaucoup. Nous sommes ce que nous faisons.

Je crois que nous pouvons faire mieux.


Voici mes huit recommandations sur la façon de créer un processus de révision des codes que les gens aiment.

1. La révision du code est meilleure sans outils

Le meilleur examen des codes est celui qui se fait en face à face. Les gens sont conçus pour échanger efficacement des informations avec des mots, le langage corporel et la voix. C’est ainsi que nous nous comprenons les uns les autres et que nous établissons des relations. Les outils transforment les humains en avatars 128×128 et les sentiments en emojis.

En ayant accès à la messagerie en ligne, les gens deviennent les pires versions d’eux-mêmes ; ils essaient alors de réparer les dégâts causés par la messagerie ; dans les bâtiments d’équipe, ils boivent et chantent des chansons d’unification. Puis ils ouvrent à nouveau les navigateurs. Et le cycle continue.

Si vous n’aimez pas vos coéquipiers, tirez sur les demandes, Slack et Gerrit vous feront les détester encore plus. Donc, pour l’amour de Dieu, arrêtez d’envoyer le code par le fil. Révisez le code en vous asseyant les uns à côté des autres – c’est beaucoup plus rapide. Si vous travaillez dans le même bâtiment et que vous examinez le travail des autres via les RP, des millions d’années d’évolution se moquent de vous. Si vous êtes à distance, essayez Tuple.

Vous n’aurez besoin que d’une check-list avec les « problèmes » que vous avez découverts lors de l’examen et qui doivent être corrigés. J’utilise des outils de haute technologie appelés papier et crayon. Croyez-le ou non, mais écrire à la main est incroyablement cool ; écrire ensemble l’est encore plus. N’oubliez pas : plus de face à face, moins d’outils.

2. La révision du code est plus un encadrement qu’un contrôle

Certaines personnes âgées considèrent la révision du code comme un moyen de contrôler la qualité et d’empêcher que de mauvaises choses ne se produisent à la production. Les personnes âgées deviennent des gardiens. Cela se heurte souvent à une résistance et à une rébellion, car le contrôle implique un manque de confiance. En outre, l’échelle n’est pas bonne lorsque votre équipe s’agrandit.

Lorsque je rencontre une équipe qui se noie dans les spaghettis mais qui résiste à la révision stricte du code, je lui propose un mentorat via la révision du code. Les développeurs l’acceptent facilement car la maîtrise est ce qui les motive le plus.

Ensuite, j’utilise le temps de révision du code que les développeurs m’ont confié pour accélérer leur croissance professionnelle : Je code des choses, j’explique des choses, je partage l’inspiration et des livres. Mon but est de me rendre inutile. Une grande équipe n’a pas besoin d’un gardien. Et parce qu’elle est bien dimensionnée, je peux me concentrer sur des tâches plus stratégiques que le contrôle d’accès. N’oubliez pas : plus de mentorat, moins de contrôle.

3. La révision du code n’est pas seulement une question de mauvaises parties

Il est facile de critiquer et de trouver des failles dans le travail d’un autre. Il suffit de regarder l’internet et les médias sociaux – le travail des gens est critiqué de manière agressive, chaque commentaire est comme une petite coupure ; ajoutez douze années d’école ; ajoutez ce que les parents ont dit ; ces coupures s’accumulent et nous commençons à nous noyer dans le doute, de peur de voler. Cet article de blog sera également critiqué.

Je pense que nous pouvons faire mieux. La critique est importante, mais la question est de savoir si vous pouvez aussi trouver et apprécier les bonnes parties.

Je commence toujours l’examen en félicitant une personne pour son travail. Ensuite, lors de la révision du code, j’accorde une attention égale aux « bonnes » et aux « mauvaises » parties de la solution. Lorsque je découvre une bonne partie, je dis « wow, c’est vraiment une bonne solution ; continuez à vous balancer ». Lorsque vous appréciez le travail des gens, ils commencent à s’ouvrir.

Quand je découvre une « mauvaise » partie, je regarde ses côtés positifs. Dans 99% des cas, lorsque vous comprenez le contexte, cette décision technique laide commence à avoir un sens. Dans 1 % des cas, lorsque ce n’est pas le cas, vous avez déjà mentionné suffisamment de bons éléments qui compensent le mauvais.

Donc, ne transformez pas la révision du code en cérémonie funéraire ; continuez à chercher les bonnes parties.

une blague où le critique, à la recherche de bonnes pièces, dit : au moins, nous n'avons pas besoin de faire des obscurcissements avant d'expédier

4. La révision du code ne tolère pas d’exceptions

Je rencontre régulièrement des équipes où les seniors passent en revue les juniors, mais les juniors ne sont pas autorisés à passer en revue les seniors. Cela crée une division malsaine dans l’équipe et conduit à une culture d’entreprise merdique : les juniors imitent le comportement des seniors ; ils commencent à penser que, le jour où ils grandiront, ils écriront un code parfait qui n’aura pas besoin d’être revu, et les seniors ont toujours raison. Vous avez probablement rencontré des seniors comme ça. Maintenant, vous savez d’où elles viennent.

Dans une organisation saine, les solutions, les idées et le code des seniors doivent être ouvertement remis en question et examinés par les juniors. Les seniors ont suffisamment de motivation, de patience et de compétences pour expliquer. Dans un tel environnement, les juniors deviennent de bons seniors ; et les seniors… eh bien, les juniors arrêtent de les traiter de connards.

Chers juniors ! J’ai beaucoup appris de vos réactions, de vos questions et de vos idées qui me semblaient alors folles. Vous avez fait de moi un meilleur programmeur, un mentor, un être humain. Je vous remercie.

5. La révision du code est un acte d’humilité

Être humble et reconnaître que l’on n’a pas toujours raison sont des conditions préalables à une bonne révision du code. Parfois, nous poussons nos solutions parce que nous voulons simplement avoir raison et que cela plaît à notre ego. Mais le développement de logiciels n’est pas un jeu à un seul joueur ; des bases de code cohérentes émergent du consensus ; un bon travail d’équipe exige des sacrifices personnels.

Parfois, lorsque je ne parviens pas à un consensus, je prends du recul et je dis « Très bien, faisons les choses à votre façon » ou « Les deux solutions semblent suffisantes. Quelle est votre préférence » ? Cela permet aux gens de se sentir concernés et leur apprend à prendre des responsabilités.

Vérifiez toujours vos antécédents.

6. La révision du code ne tolère pas les jugements abstraits

Qualifier un code de « mauvais », « de merde » ou « illisible » est un jugement subjectif et abstrait. Il offense les gens et provoque une résistance. Certaines qualités du code mènent à une conversation productive :

  • la conformité aux exigences
  • la conformité aux normes et règles sur lesquelles l’équipe s’est accordée
  • couverture par des tests
  • couplage
  • cohésion
  • réutilisabilité
  • découverte
  • duplication
  • verbosité
  • compréhensibilité
  • charge cognitive
  • les niveaux d’abstraction
  • etc.

Il s’agit de votre nouveau langage de révision des codes.

Il est également important d’apprendre à démontrer l’impact de ces qualités en action : casser le code pour démontrer la valeur d’un test unitaire ; écrire un test pour simuler une mauvaise performance ; déplacer une classe vers un autre emballage pour démontrer le couplage ; demander à une troisième personne de lire le code et d’expliquer ce que fait le code ; c’est ainsi que vous évaluez la compréhensibilité. Soyez concret dans votre jugement et créatif dans vos manifestations.

7. La révision du code est un « bloqueur ».

Si la révision des codes n’est pas une priorité absolue, c’est que quelque chose ne va pas avec vos priorités. Ou bien vous laissez le travail s’accumuler puis vous le livrez par lots, ce qui empêche de livrer continuellement de la valeur au client.

Dans une mauvaise équipe, la révision du code est la dernière priorité. Les demandes de tirage restent ouvertes pendant des jours, parfois des semaines, voire des mois. Chacun est occupé à faire « ses propres trucs ». Cela tue la motivation car notre travail ne semble pas important. Pour éviter l’inactivité, nous commençons à travailler sur de nouvelles tâches, puis nous retournons à la révision du code, puis nous recommençons. La productivité diminue.

Dans une bonne équipe, la révision des codes est la première priorité. Vous levez la main en criant : « J’ai besoin de la révision du code ! ». Parce que vous n’êtes qu’à un pas de fournir de la valeur au client, un coéquipier vous répond immédiatement : « J’arrive ! » et déplace sa chaise à côté de vous. Ensuite, vous faites une révision, quelques corrections, tout en vert. Poussez. L’émission est en direct. Le trafic commence à arriver ; aucune erreur dans les journaux. La valeur a été livrée et vous marquez la tâche terminée. Avec le réviseur, souriant, vous allez à la cuisine pour prendre un café.

Faire de la révision du code la première priorité ; c’est un bloqueur.

8. La révision du code est meilleure lorsque vous êtes préparé

Pour que l’examen des codes soit court et efficace, le destinataire doit se préparer soigneusement. Respectez votre examinateur et pensez à la façon dont vous allez l’expliquer :

  • La tâche ou l’élément sur lequel vous travaillez
  • Le problème que vous avez tenté de résoudre
  • Le raisonnement qui sous-tend les décisions en matière de conception

Utilisez des notes et notez les choses importantes. Mieux vous expliquerez le problème à l’examinateur, plus l’examen sera approfondi et utile. Sinon, c’est une perte de temps.

Afficher le code par petits incréments. N’attendez pas que votre article de deux semaines soit terminé, car de telles critiques consomment trop de temps et d’énergie. Elles entraînent également trop de travail supplémentaire, si vous vous êtes trompé dans les exigences. Utilisez git commits pour raconter l’histoire en petits chapitres, classés par ordre chronologique. Montrez un engagement à la fois.

Conclusion

Le processus de révision de votre code peut être une torture. Tout comme ceci :

Des gens en colère qui revoient le code

Elle peut aussi être une activité efficace, encourageante et positive. Juste comme ça :

Des personnes heureuses de revoir le code

La différence réside dans les détails de mise en œuvre. Pour que la révision du code soit parfaite, n’oubliez pas :

  • La révision du code est meilleure sans outils
  • La révision du code est plus un encadrement qu’un contrôle
  • La révision du code est un « bloqueur ».
  • La révision du code est un acte d’humilité
  • La révision du code n’est pas seulement une question de mauvaises parties
  • La révision du code est meilleure lorsque vous êtes préparé
  • La révision du code ne tolère pas d’exceptions
  • La révision du code ne tolère pas les jugements abstraits

Je vous remercie de votre attention.


Pendant ma formationNous couvrons et simulons différentes situations de révision de code. Si vous souhaitez renforcer vos compétences en matière de révision de code, participez.

Soyez le premier à commenter

Poster un Commentaire

Votre adresse de messagerie ne sera pas publiée.


*