Cette semaine, j'ai beaucoup réfléchi à la communication entre les développeurs et les non-développeurs, et à la forme spécifique des revues de code. Après tout, les revues de code sont riches en occasions de malentendus, de conflits et de frustrations. Mais il n'est pas nécessaire qu'il en soit ainsi. Voici trois conseils pour s'assurer que les revues de code se déroulent sans heurts 

J'utilise les revues de code pour apprendre comment les autres pensent et codent. Et pour grandir. Si quelque chose dans le code me semble erroné, il s'agit souvent d'une erreur ou d'un oubli de la part du développeur. Mais il peut aussi s'agir d'un malentendu ou d'un manque de connaissances de ma part. Formuler mes commentaires sous forme de questions permet d'atténuer le choc. (Et cela signifie que j'ai l'air moins stupide si j'ai tort).

Ne partez jamais du principe que vous savez. Ne cessez jamais d'apprendre.

Ne dites pas : « Ce n'est pas la bonne façon de faire ».

Dites plutôt : « Je ne comprends pas pourquoi vous procédez de cette façon, parce que... »

S'il y a matière à amélioration, il est tentant d'expliquer d'emblée quelle est la meilleure solution. Mais le mentorat consiste aussi à aider les autres à s'approprier la solution. Et pour cela, il faut qu'ils travaillent pour y parvenir, et non qu'on leur impose la solution.

C'est en faisant les choses que l'on apprend, pas en se les faisant dire.
Ne dites pas : « Voici la solution : ... »

Dites plutôt : « Je pense que vous pourriez améliorer le code. As-tu pensé à... »

Les révisions de code ne doivent pas se faire dans une seule direction. Le fait de recevoir une évaluation m'aide à comprendre ce que je peux améliorer : non seulement ma façon de coder, mais aussi ma façon de réviser. Cela nécessite de mettre mon ego de côté, ce qui peut être difficile. Mais si vous voulez grandir :

Ne limitez pas le nombre de personnes qui peuvent évaluer votre travail.

Demandez du feedback largement

Vous avez peut-être remarqué un thème commun à ces trois conseils : choisir la voie difficile plutôt que la voie facile. Choisir la générosité et l'humilité. Cela peut être douloureux. Cela peut être difficile. Mais c'est toujours gratifiant. C'est du moins ce que j'ai constaté 🙂 . 

React Scan propose un drop-in d'une ligne qui met en évidence les composants mis à jour dans React, et vous donne un moyen rapide et facile de voir s'ils sont excessivement mis à jour (ce qui ralentira votre application). Il a été conçu par la même société qui a publié l'outil d'optimisation React « Million ». 

Framer et Framer Motion étaient auparavant un concept confus entre l'outil de création de pages (Framer) et la bibliothèque d'animation React (Framer Motion). Framer Motion a maintenant été isolé, passé en open-source, et il cible plus que seulement React. 

Payload, le CMS NextJS qui vise à prendre des parts de marché à WordPress, vient de sortir sa version v3 qui a été réécrite en NextJs, tirant le meilleur parti de ses (relativement nouvelles) capacités côté serveur. A suivre de près, je compte bien l’explorer et si ça a du sens, faire une vidéo dessus!

Merci d'être venus jusqu'ici. Faites-moi savoir ce que vous avez pensé de ce numéro de la newsletter afin que je puisse mieux répondre à vos besoins via ce très court sondage ou simplement en répondant à cet email ! 

David de Kodaps