Comment gérer le code «presque bon» d'un développeur junior?
J'ai une question sur la gestion d'équipe. En ce moment, j'ai affaire à un développeur junior qui travaille à distance depuis une usine de codage. Le gars est ouvert à la critique et désireux d'apprendre, mais j'ai des doutes sur la quantité de données à pousser.
En ce moment, lorsque quelque chose est clair et évident, une violation des bonnes pratiques: comme la violation de SRP, des objets de Dieu, des noms non significatifs pour les méthodes ou les variables; Je souligne ce qu'il doit corriger et j'essaie d'expliquer pourquoi c'est mal.
Ma question est: quand dois-je arrêter? En ce moment, s'il y a des violations mineures du style de codage comme les noms de variables dans la mauvaise langue (l'équipe précédente mélangeait espagnol et anglais et j'essaie de résoudre ce problème), ou quelques problèmes structurels mineurs que je laisse aller et corrige si J'ai du temps libre ou j'ai besoin de modifier la classe problématique. Je pense que c'est bon pour le moral de l'équipe, donc je ne repousse pas constamment le code sur ce qui pourrait sembler mineur à un novice, ce qui peut être assez frustrant, mais je crains également qu'être trop `` doux '' puisse empêcher le gars d'apprendre à faire des choses.
Comment puis-je équilibrer la ligne entre enseigner au gars et ne pas le brûler avec des critiques constantes? Pour un junior, cela peut être frustrant si vous lui dites de refaire des choses qui fonctionnent à ses yeux.
Si vous pensez que le code doit être corrigé avant la fusion, faites des commentaires. De préférence avec "pourquoi" pour que le développeur puisse apprendre.
Gardez à l'esprit que le code est lu beaucoup plus souvent qu'écrit. Ainsi, les choses qui semblent "mineures" peuvent en fait être vraiment importantes (noms de variables par exemple).
Cependant, si vous vous retrouvez à faire des commentaires qui semblent fastidieux, envisagez peut-être:
- Votre processus CI devrait-il les attraper?
- Avez-vous un "guide du développeur" clair à référencer (ou tout est-il documenté dans votre tête)?
- Ces commentaires contribuent-ils réellement à la qualité du code?
Beaucoup de gens sacrifient la productivité sur l'autel du processus ou de la perfection. Attention, vous ne faites pas ça.
Essayez de rendre visite à votre collègue en personne si possible. Ou utilisez des appels vidéo. L'établissement d'une relation facilite la gestion des critiques (même des révisions de code).
Si vous trouvez qu'un morceau de code a trop de va-et-vient sur les problèmes, demandez la révision sur des morceaux de code plus petits. Les changements incrémentiels sont plus susceptibles d'éviter certains des problèmes de conception les plus importants, car ils sont par définition plus petits.
Mais il faut absolument pas fusionner des trucs puis revenir en arrière et le réparer. C'est passif agressif et si le développeur vous trouve faire cela, vous tuerez leur moral.
Gardez la critique sur le code plutôt que sur l'écrivain.
Tout travail produit s'accompagne d'un attachement émotionnel inhérent. Envisagez de faciliter cela en dissociant le code de l'écrivain autant que possible. La qualité du code doit être systématiquement établie comme un objectif mutuel auquel vous êtes tous deux confrontés, plutôt que comme un point de friction entre vous.
Une façon d'y parvenir est de choisir judicieusement vos mots. Bien que les individus STEM aiment se considérer comme très logiques, les émotions font partie de la nature humaine. Le verbiage utilisé peut faire la différence entre des sentiments blessés ou épargnés. Dire "Ce nom de fonction serait plus cohérent avec les conventions s'il était en anglais" est préférable à "Vous avez mal écrit ce nom de fonction et il devrait être en anglais". Bien que ce dernier soit encore apprivoisé et seul semble correct, par rapport au premier, ses défauts deviennent évidents - lors de la préparation de ce qu'il faut dire en personne ou par courrier électronique, examinez si votre contexte, les mots et l'accent sont mis sur le problèmes plutôt que la personne.
Le langage du corps
Bien que les mots soient importants, la plupart des communications sont non verbales. Faites attention au langage corporel, même à des subtilités apparemment insignifiantes, comme l'orientation, par exemple De nombreuses interactions senior-junior se produisent en face à face, mais une approche côte à côte serait beaucoup plus propice au résultat souhaité.
Donner une rétroaction positive honnête
Une multitude d'études montrent que les informations sont apprises plus rapidement et mieux conservées lorsque nous récompensons les bons comportements plutôt que de punir les mauvais. Parfois en notant simplement que les performances ont été améliorées avec un simple "bon travail" ou un plus spécifique "J'ai remarqué récemment que votre style correspondait à nos normes avec un tee-shirt, excellent travail!" même en complétant cette reconnaissance de l'amélioration en les faisant, à leur tour, conseiller quelqu'un d'autre sur les problèmes qu'ils ont modifiés, cela peut faire toute la différence pour votre développeur junior et son travail.
Sur la base de votre description, je me contenterais de: "c'est bien. Il y a quelques choses que j'aurais faites différemment mais elles ne sont pas très importantes."
Comme vous semblez le comprendre, la critique a un coût et si vous passez beaucoup de temps à ronger les détails, cela devient un problème de moral. Idéalement, toutes les normes de codage sont vérifiées automatiquement et vous ne pouvez pas les construire à moins de les suivre. C'est un énorme gain de temps et vous permet de vous mettre au travail. Si vous réservez vos critiques aux "choses qui comptent", vos conseils auront beaucoup plus d'impact et vous serez considéré comme un mentor apprécié. Il est vraiment crucial de faire la distinction entre les choses qui ne sont pas bonnes et les choses qui ne sont pas exactement comme vous le feriez.
Je crois au concept du moment propice à l'apprentissage . Si le développeur a une capacité mentale suffisante, il peut demander des détails sur ce que vous feriez différemment. (S) il ne pourrait pas et c'est OK. Les gens s'épuisent et au début d'une carrière, cela peut prendre beaucoup d'énergie mentale pour accomplir des choses qui semblent simples plus tard.
J'envisagerais d'accepter son travail quand il est acceptable, pas parfait. Et puis la tâche suivante est après une discussion pour la refactoriser immédiatement en faisant tous les petits mais importants changements que vous souhaitez.
Donc, quand votre travail est accepté pour la première fois, votre message est qu'il n'était pas mauvais, et certains endroits l'auraient accepté comme assez bon - mais pas des endroits où vous voudriez être un développeur junior qui veut apprendre correctement son métier.
Vous ne dites donc pas "je rejette votre travail parce qu'il n'est pas assez bon". Vous dites (a) "J'accepte votre travail parce qu'il est assez bon", puis (b) "Mais je le veux mieux".
Le gars est ouvert à la critique et prêt à apprendre, mais j'ai des doutes sur la quantité de données à pousser.
Poussez tout ce que vous pouvez. Si le gars apprend et que c'est votre travail de revoir son code, vous avez tous les deux beaucoup à gagner s'il fait du bon travail.
Cela signifie moins de code à réviser à l'avenir, et peut-être donner à votre équipe un objectif d'embauche.
De plus, si vous vous retenez, vous n'aidez pas, mais vous condescendez.
Juste par le fait que vous avez posté votre question ici, demandant si vous en faites trop, me signe déjà que vous n'avez pas besoin de ce conseil spécifique, mais pour d'autres, la voici: rappelez-vous simplement que pousser fort ne signifie pas être un imbécile.
Être mentor n'est pas une tâche facile. Vous devrez également lui laisser de l'espace pour faire des erreurs et les corriger par lui-même, assurez-vous simplement qu'il fera cela quelque part qui ne fait pas de dégâts réels.
Question assez ouverte, mais voici quelques idées.
Examens par les pairs (par le développeur junior)
La meilleure façon pour quelqu'un d'apprendre la "bonne" façon est de voir les autres le faire. Tous vos développeurs effectuent-ils des révisions de code? Ce n'est peut-être pas une mauvaise idée de laisser votre développeur junior les exécuter également (même si vous devez également demander au moins un examen à un développeur senior). De cette façon, il verra de bons codeurs en action, et il observera qu'il y a des commentaires de révision adressés à des ingénieurs autres que lui, ce qui signifie que ce n'est pas personnel.
Rétroaction précoce/examens des tâches
Autorisez le développeur à participer à sa propre répartition des tâches. Demandez-lui d'enregistrer sa conception prévue dans les notes de tâche et de soumettre une "révision de code" sans changement et uniquement la tâche. De cette façon, vous pouvez revoir son plan avant qu'il n'ait écrit une seule ligne de code. Une fois sa tâche passée en revue, il peut commencer à coder (après quoi il soumettra une autre revue de code). Cela évite la situation démoralisante où le développeur a écrit un tas de trucs et vous devez lui dire de le réécrire.
Si le code viole objectivement une norme écrite et non ambiguë, je pense que vous devriez simplement continuer à repousser jusqu'à ce que chaque problème soit résolu. Bien sûr, cela peut être légèrement ennuyeux pour le développeur les premiers commits, mais ils pourraient aussi bien apprendre les directives plus tôt que tard.
De plus, si vous autorisez quelques violations des normes ici et là, elles créeront un mauvais précédent - voir théorie des fenêtres cassées . En outre, il est beaucoup plus facile de se rappeler de suivre les normes si elles sont déjà appliquées de manière cohérente à la base de code. Donc vraiment, tout le monde y gagne, y compris les développeurs juniors en question.
Je ne pense pas que le moral soit un gros problème tant que la norme de codage est écrite. Seulement si cela entre dans un sens plus subjectif "eh bien, [~ # ~] je [~ # ~] l'aurais fait différemment" -territoire, alors vous devrait être concerné, car l'approche des développeurs pourrait être tout aussi valable.
Envisagez d'adopter un flux de travail de révision de code, dans lequel les développeurs publient leurs propositions de validations dans un outil comme Github Pull Requests ou Phabricator Diffusion et obtiennent l'approbation des pairs avant d'atterrir leurs modifications sur la branche principale partagée.
De cette façon, plutôt que de critiquer rétroactivement ou de demander à quelqu'un de refaire ce qui a déjà été fait, le travail est simplement pas encore fait jusqu'à ce qu'il passe l'examen par les pairs. Le va-et-vient avec les pairs fait autant partie du processus d'ingénierie logicielle que le va-et-vient avec le compilateur.
Vous pouvez publier vos préoccupations sous forme de commentaires sur des lignes particulières et avoir des discussions à ce sujet. Il peut faire de même avec votre code. La discussion reste concentrée sur les changements de code proposés et non sur les performances ou les compétences de quelqu'un en général.
Même les brillants ingénieurs de mon entreprise sont reconnaissants lorsque les revues de code détectent des fautes de frappe ou les forcent à clarifier les choses. Il est tout à fait normal que les nouvelles recrues nécessitent plus de cycles d'itération. Au fil du temps, vous commencez à corriger par réflexe les types de problèmes que vous savez attirer des commentaires avant poster un diff. Obtenir un pourcentage plus élevé de vos différences acceptées du premier coup est la façon dont vous savez que vous vous améliorez.
Je ne repousse pas constamment le code sur ce qui pourrait sembler mineur à un novice, ce qui peut être assez frustrant, mais je crains également qu'être trop `` doux '' n'empêche le gars d'apprendre à faire des choses.
Ce sont à la fois de réelles possibilités et des préoccupations valables. Demandez au développeur ce qu'il en pense.
En supposant que vous ayez un flux de travail de demande de tirage ou de révision de code, et il semble que ce soit le cas, je recommanderais de noter les choses qui sont "non critiques" ou "préférées".
Si vous voyez un PR dans un état similaire à ce que vous décrivez, avec quelques problèmes stylistiques mineurs ou ayant besoin d'une refactorisation non critique, laissez un commentaire, mais n'hésitez pas à approuver. Dire quelque chose comme "À l'avenir, essayez peut-être d'éviter les noms de méthode comme celui-ci au profit de quelque chose comme descriptiveMethodName" documente votre opinion sans les forcer à le changer, ni bloquer leur développement.
Maintenant, ils connaissent votre préférence, et s'ils essaient de s'améliorer, ils devraient, espérons-le, remarquer une telle situation à l'avenir. Cela leur laisse également la porte ouverte pour le changer à ce moment-là, s'ils sont d'accord avec vous et le considèrent comme suffisamment critique.
Une autre idée pour faire face à "trop de critiques" est de faire de temps en temps une tâche par vous-même et de laisser le développeur junior faire une révision de code pour vous. Cela présente au moins deux avantages:
- ils peuvent voir comment vous vous attendez à ce que les choses soient faites.
- dans les cas où il existe plusieurs bonnes solutions ou noms de variables, j'accepte les suggestions d'approches différentes mais (presque?) tout aussi bonnes. Lorsque je corrige mon code à cause du commentaire de quelqu'un, j'essaie de montrer aux gens qu'ils sont respectés et la critique concerne toujours uniquement le code - quel que soit l'auteur.
J'ai affaire à un développeur junior qui travaille à distance depuis une usine de codage.
Ce n'est malheureusement pas une situation idéale: un programmeur avancé en charge d'un programmeur novice, avec séparation géographique. Il n'est pas surprenant qu'il y ait une certaine tension, mais la disparité peut être atténuée.
Je suis curieux, que voulez-vous dire par "usine de codage"? Cette terminologie, pour moi, indique une attitude troublante qui peut exacerber certains des problèmes de gestion que vous avez mentionnés.
… Violation du SRP, des objets divins, des noms non significatifs pour les méthodes ou les variables; Je souligne ce qu'il doit corriger et j'essaie d'expliquer pourquoi c'est mal.
Le problème, je pense, est que votre développeur junior crache du code sans avoir suivi un processus de conception approprié. C'est un échec de votre part, en tant que manager et développeur senior, à fournir des conseils et à enseigner de bonnes habitudes de développement logiciel. Vous pouvez empêcher le mauvais code d'être écrit en premier lieu si vous travaillez d'abord ensemble pour esquisser un plan. Cela serait préférable à la critique et à la réécriture du code après sa production, en termes d'efficacité et de moral.
Vous devrez probablement réajuster votre flux de travail. Il semble que vous vous attendiez actuellement à ce qu'il vous livre des produits. Ce dont vous avez besoin, c'est d'une collaboration plus étroite, afin de pouvoir vous guider à chaque étape du développement. Parlez de la conception et de l'interface avant le début du codage. Pendant le codage, effectuez des contrôles plus fréquents pour détecter les problèmes plus tôt. Si possible, essayez la programmation par paire, via le partage d'écran avec un canal audio.
Tout cela nécessitera plus d'efforts de votre part, mais cela vaudra probablement la peine, compte tenu de la relation problématique que vous avez actuellement.