Comment encourager les développeurs juniors à participer à la révision du code?

Je travaille actuellement en tant que développeur senior avec 3 juniors en dessous de moi et j'ai introduit un processus de révision de code pour aider à gérer la qualité du code en cours de production.

Je pense que c'est très bénéfique pour nous tous de passer en revue le travail de chacun, mais après environ 5 semaines de processus, je suis le seul à faire des commentaires dans l'outil (BitBucket).

Je pense qu'il y a en partie des problèmes culturels au travail, et peut-être une réticence naturelle au cas où leurs commentaires seraient faux, mais y a-t-il un moyen et je peux aider les juniors à se sentir plus à l'aise de critiquer le mien et de travailler les uns les autres?

Pour moi, la question ici est "que cherchez-vous pour vos développeurs juniors pour sortir des revues de code?". Pour moi, la chose la plus importante est potentiellement pour les développeurs juniors d'apprendre en regardant ce qui est, espérons-le, un bon code; s'ils trouvent également des problèmes dans votre code, c'est un bonus.

Si vous cherchez à ce que votre personnel subalterne apprenne des révisions de code, la chose la plus importante que vous devez faire est de créer un environnement où l'apprentissage est valorisé et non pas considéré comme une perte de temps. Cela signifie un certain nombre de choses:

• Il n'y a pas de question stupide . Si quelqu'un ne comprend pas un peu de code, pourquoi vous avez utilisé un certain modèle ou autre, il doit se sentir libre de demander, sans jamais avoir l'impression de perdre son temps ou celui des autres développeurs .
• Le temps passé à apprendre est du temps bien utilisé . Vous voulez que vos développeurs juniors passent du temps à regarder le code et à en tirer des leçons, car cela leur permettra de devenir un personnel meilleur et plus productif à l'avenir. À moins qu'il ne s'agisse d'un correctif essentiel qui doit être révisé maintenant , encouragez-les à consacrer plus de temps, plutôt que moins, aux révisions de code.
• Les cadres supérieurs n'ont pas toujours raison . Ce n'est pas parce que vous faites cela depuis plus longtemps que vous avez raison. S'ils pensent avoir trouvé un bug, ils ont probablement raison. S'ils pensent qu'un autre modèle de conception serait approprié pour ce morceau de code, alors ils doivent se sentir libres de le dire sans obtenir de commentaires négatifs.

Organisez des réunions d'examen du code en personne à heure fixe chaque semaine. J'ai vendu ça à mon coéquipier comme ça (nous sommes en fait tous les deux des développeurs seniors, mais peu importe):

"L'examen du code est en partie là pour que je puisse mieux connaître votre code et savoir ce qui se passe dans votre côté au cas où vous seriez heurté par un camion un jour et que l'on m'ordonnerait de terminer votre sprint. Mais principalement c'est là pour que vous expliquiez votre code à quelqu'un d'autre, car lorsque vous faites cela, il engage une autre partie de votre cerveau, et souvent votre explication, et / ou leurs questions ou commentaires, peut vous faire vous souvenir de quelque chose que vous avez oublié à faire dans le code, ou pourrait vous amener à réaliser une meilleure façon de le rendre plus lisible ou de mieux l'architecturer. Cela conduit à un code plus beau. "

J'aime à le voir comme un show-and-tell. Les gens peuvent montrer leur travail à leurs pairs. Il ne s'agit pas que vos pairs trouvent des choses erronées dans votre travail, dont personne n'aime le sentiment. Il s'agit d'impressionner vos pairs avec votre code génial, dont tout le monde aime la sensation.

Cependant, je pense qu'en utilisant des outils de révision de code où il n'y a pas d'interaction humaine, pas de réunion dans une pièce, pas de tableau blanc .. cela devient juste une autre "chose" ennuyeuse à faire. Ce n'est pas qu'il ne devrait pas y avoir de tels outils, mais ils devraient être quelque chose que vous avez recours si, lors de la réunion de révision du code, il est réalisé qu'un examen plus approfondi d'une certaine section de code pourrait être nécessaire. Ensuite, vous pouvez affecter l'un des développeurs juniors à revoir le code de l'autre sur une certaine zone.

Vous pouvez aider en donnant un bon exemple. Vous ne pouvez pas être sur la défensive lorsque quelqu'un souligne vos erreurs. Examinez votre code et notez les domaines à améliorer. Partagez cela avec l'équipe. Finalement, ils apprendront que cela est encouragé et personne ne se fera battre pour avoir un bug dans leur code.

Avoir un emploi signifie prendre ses responsabilités et être fier de son travail. Si la révision du code en fait partie, alors la participation à la révision du code devrait être incluse dans les évaluations. J'ai suivi des cours en ligne où la participation à des discussions en ligne fait partie de la note. Les commentaires doivent être développés. "Je suis d'accord" n'est pas acceptable.

La révision du code devrait améliorer le code. Selon votre situation, il peut être mesuré par les chiffres de vente, les plaintes des utilisateurs ou toute autre note si vous écrivez du code à usage interne. La réalité est que votre code sert à quelque chose et votre équipe doit être mesurée par la façon dont elle sert cet objectif. Ceux que vous déterminez contribuent au succès, vous pouvez partager proportionnellement les récompenses.

Concentrez-vous sur la publication d'un code de qualité. L'objectif n'est pas que tout le monde se sente bien en évitant les bugs. J'écris du mauvais code; Je dois corriger le mauvais code. C'est le travail et la vie. Je déteste corriger les bugs, alors j'essaye de les éviter. Je suis fier de mon travail, donc cela me dérange lorsque mon code ne fonctionne pas. Je me sens mal pour les utilisateurs ou toute autre personne qui doit prendre son temps pour signaler ces choses et cela me motive à vouloir y remédier.

En passant, si vous avez un environnement où personne ne peut donner ou accepter une critique constructive, vous avez un problème.

Le processus: quelqu'un veut valider ses modifications. Quelqu'un est désigné comme réviseur et examine les modifications. Les modifications révisées et corrigées sont ensuite testées.

Si le test détecte des bogues introduits dans la modification, l'auteur et le réviseur sont également à blâmer.

Donc, faire un examen sans aucun commentaire vous causera des ennuis à moins que le code ne soit parfait.