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


13

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?


2
Je me demande si ce ne serait pas une meilleure question pour Workplace.SE, mais mes 2 cents en tant que développeur junior. Pendant que j'étais stagiaire, j'étais très nerveux à l'idée de participer à des révisions de code pour plusieurs raisons: manque de compétences, manque de familiarité avec la base de code, etc. J'ai rapidement découvert que la participation à la révision de code aidait à ces deux aspects ( particulièrement la familiarité), et a également été très utile en me faisant sentir que notre base de code était quelque chose qui m'intéressait, alors je voulais contribuer. Je n'ai certainement pas toujours laissé de bons commentaires, mais je ne savais pas jusqu'à ce que (suite)
Dannnno

2
(suite) essayé et cela m'a aidé à mieux travailler avec l'équipe dans son ensemble. Je pense que si vous essayez d'expliquer pourquoi il est utile pour vous, l'équipe et la base de code pour eux de participer, même si leurs commentaires sont faux; si leurs commentaires sont faux, c'est presque mieux car ils peuvent alors en tirer des leçons.
Dannnno

Réponses:


15

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.

Merci beaucoup pour votre contribution, je vais y réfléchir et en discuter demain dans notre stand
Graham S

1
J'ajouterais: pour devenir un expert, il faut commettre des erreurs et en tirer des leçons. en pratique, il pourrait être utile pour le sr. devs pour raconter quelques histoires de guerre sur leurs erreurs passées.

5

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.


+1 pour engager une autre partie de votre cerveau. D'après mon expérience, en particulier lorsque j'étais un développeur junior, le simple fait de savoir que mon code allait être révisé par des pairs m'a fait prêter attention à des détails que j'aurais sinon pu ignorer.
Laconic Droid

0

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.


-3

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.


5
1) Assigner le "blâme" pour les bogues est un excellent moyen de faire partir votre personnel 2) Assigner le blâme au personnel subalterne pour ne pas avoir repéré les bogues écrits par le personnel senior est doublement mauvais.
Philip Kendall

2
@PhilipKendall Si mon code a un bug, personne n'a besoin de me blâmer. Je suis un professionnel et je suis vraiment fier et responsable de mon travail. Est-ce une sorte de nouvel âge où personne ne fait de mal et tout le monde reçoit un trophée pour sa participation?
JeffO

@PhilipKendall: Je ne sais pas où tu travailles ... Là où je travaille, je dirai "quelle erreur stupide j'ai faite" et le critique dit "et je l'ai raté aussi" et puis nous rions tous les deux. "Blâmer" signifie prendre ses responsabilités, ne pas rester dans le coin avec un chapeau de cancre.
gnasher729

1
@ gnasher729 Oui. Mais personne n'a "d'ennuis" pour cela.
Philip Kendall
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.