Comment gérer le code "presque bon" d'un développeur junior? [fermé]

J'ai une question sur la gestion d'équipe. En ce moment, je traite avec un développeur junior qui travaille à distance depuis une usine de codage. Le gars est ouvert à la critique et disposé à apprendre, mais je me demande si je devrais pousser des choses.

À l’heure actuelle, une violation évidente des bonnes pratiques est évidente: comme une violation de la SRP, des objections de Dieu, des noms non significatifs pour des méthodes ou des variables; Je montre ce qu'il doit réparer et j'essaie d'expliquer pourquoi c'est faux.

Ma question est: quand est-ce que je m'arrête? À l'heure actuelle, s'il y a des violations mineures du style de codage telles que des noms de variables dans la mauvaise langue (l'équipe précédente avait mélangé l'espagnol et l'anglais et que j'essayais de résoudre ce problème), ou des problèmes structurels mineurs, je les laisse résoudre le problème si J'ai du temps libre ou besoin de modifier la classe problématique. Je pense que cela est bon pour le moral des équipes, donc je ne repousse pas constamment le code sur ce qu'un débutant pourrait avoir l'impression d'être des détails mineurs, ce qui peut être assez frustrant, mais je crains aussi que le fait d'être trop "doux" puisse empêcher le gars d'apprendre à faire des choses.

Comment puis-je équilibrer la ligne entre enseigner le gars et ne pas l'épuiser avec des critiques constantes? Pour un junior, il peut être frustrant de lui dire de refaire ce qui fonctionne à 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 dev puisse apprendre.

Gardez à l'esprit que le code est lu beaucoup plus souvent qu'écrit. Donc, les choses qui semblent "mineures" peuvent réellement être vraiment importantes (noms de variables par exemple).

Cependant, si vous vous trouvez en train de faire des commentaires qui semblent fastidieux, envisagez peut-être:

• Est-ce que votre processus de CI devrait 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é à l'autel du processus ou de la perfection. Attention à ne pas faire ça.

Essayez de rendre visite à votre collègue en personne si possible. Ou utilisez des appels vidéo. Construire une relation facilite la gestion des critiques (même des critiques de code).

Si vous trouvez qu'un morceau de code a trop de va-et-vient sur les problèmes, demandez la révision plutôt que des morceaux de code plus petits. Les modifications incrémentielles sont plus susceptibles d'éviter certains des problèmes de conception les plus importants, car elles sont par définition moins importantes.

Mais il ne faut absolument pas fusionner des éléments, puis revenir en arrière et les réparer. C'est passif agressif et si le développeur trouve que vous faites cela, vous tuez leur moral.

Gardez la critique sur le code plutôt que sur l'auteur.

Tout travail produit comporte un attachement émotionnel inhérent. Pensez à atténuer cela en dissociant le plus possible le code de l'écrivain. La qualité du code doit toujours être établie comme un objectif commun 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 hautement 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 conforme aux 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 bien, par rapport à l'ancien, 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, vos mots et votre attention sont ou non centrés sur les problèmes. 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 aux subtilités apparemment insignifiantes telles que la matière d'orientation. Par exemple, de nombreuses interactions entre jeunes seniors se font face à face. Cependant, une approche côte à côte serait beaucoup plus propice au résultat souhaité.

Donner des commentaires positifs honnêtes

Une multitude d’études montrent que les informations sont apprises plus rapidement et mieux retenues lorsque nous récompensons les bons comportements plutôt que de punir les mauvais. Parfois, il suffit de noter que les performances ont été améliorées avec un simple "bon travail" ou un mot plus spécifique "J'ai récemment remarqué que votre style correspondait à nos normes à un tee-shirt, excellent travail!" Même en complétant cette reconnaissance d'amélioration en leur demandant, à leur tour, de conseiller quelqu'un d'autre sur les problèmes qu'ils ont modifiés peut faire toute la différence pour votre jeune développeur et son travail.

Le gars est ouvert à la critique et disposé à apprendre, mais je me demande si je devrais pousser des choses.

Poussez tout ce que vous pouvez. Si le gars apprend et qu'il est de votre devoir de revoir son code, vous avez beaucoup à gagner s'il fait du bon travail.

Cela signifiera moins de code à réviser dans le futur et donnera éventuellement à votre équipe un objectif d'embauche.

En outre, si vous vous retenez, vous n’aidez pas, mais vous condescendez.

Le simple fait que vous avez posté votre question ici, demandant si vous en faites trop, me signale déjà que vous n'avez pas besoin de ce conseil spécifique, mais pour les autres, le voici: rappelez-vous que pousser fort ne veut pas dire être un imbécile.

Être un mentor n'est pas une tâche facile. Vous devrez également lui laisser un espace pour faire des erreurs et les corriger lui-même. Assurez-vous simplement qu'il le fera quelque part sans faire de véritables dégâts.

Sur la base de votre description, je la laisserais à: "c’est bien. Il ya quelques choses que j’aurais faites différemment mais qui ne sont pas très importantes."

Comme vous semblez le comprendre, la critique a un coût et si vous passez beaucoup de temps à détailler des 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 construire si vous ne les suivez pas. C'est un gain de temps considérable et vous permet de vous mettre au travail. Si vous réservez vos critiques pour des «choses qui comptent», vos conseils auront beaucoup plus d'impact et vous serez perçu comme un mentor précieux. 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 suffisamment de capacité mentale, il peut demander des détails sur ce que vous feriez différemment. (S) il pourrait ne pas et c'est OK. Les gens s'épuisent et au début de leur carrière, il peut falloir beaucoup d'énergie mentale pour accomplir des choses qui semblent simples plus tard.

Je considérerais accepter son travail quand il est acceptable, pas parfait. Et ensuite, la tâche suivante consiste, après une discussion, à la refactoriser immédiatement en effectuant tous les changements mineurs mais importants que vous souhaitez.

Ainsi, quand le travail est accepté pour la première fois, votre message est que ce n’est pas mauvais et que certains endroits l’auraient jugé assez bon - mais pas des endroits où vous voudriez être un développeur junior qui veut apprendre son métier correctement.

Donc, vous ne dites pas "je rejette votre travail parce que ce 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".

Question assez ouverte, mais voici quelques idées.

1. Évaluations par les pairs (par le développeur junior)

   Le meilleur moyen pour quelqu'un d'apprendre le "bon" moyen est de voir les autres le faire. Est-ce que tous vos développeurs effectuent des revues de code? Ce n’est peut-être pas une mauvaise idée de laisser votre développeur junior les exécuter également (bien que vous deviez également exiger au moins un examen d’un développeur senior également). De cette façon, il verra de bons codeurs en action, en plus de constater qu'il existe des commentaires de révision destinés à des ingénieurs autres que lui-même, ce qui signifie que cela est personnel.

2. Premiers commentaires / évaluations de tâches

   Autoriser le développeur à participer à sa propre répartition des tâches. Demandez-lui d’enregistrer sa conception dans les notes de tâches et de soumettre une «révision de code» sans ensemble de modifications et uniquement pour 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 que sa tâche a été passée en revue, il peut commencer à coder (après quoi il soumettra une autre révision de code). Cela évite la situation démoralisante dans laquelle le développeur a écrit un tas de choses et que vous devez lui dire de le réécrire.

Si le code enfreint de manière objective une norme écrite et non ambiguë, je pense que vous devriez simplement continuer à pousser jusqu'à ce que chaque problème soit résolu. Certes, les premiers commits pourraient être légèrement gênants pour le développeur, mais ils pourraient tout aussi bien connaître les règles à suivre plus tôt que plus tard.

En outre, si vous permettez quelques infractions aux normes ici et là, elles créeront un mauvais précédent - voir la 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 devient plus subjectif "bien, je l' aurais fait différemment" -territory, alors vous devriez être inquiet, 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 modifications proposées sur un outil tel que Github Pull Requests ou Phabricator Diffusion et obtiennent la signature de leurs homologues avant d'imposer leurs modifications à la branche maîtresse 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 n'est tout simplement pas terminé jusqu'à ce qu'il passe l'examen par les pairs. Les échanges avec les pairs font autant partie du processus d’ingénierie logicielle que les échanges avec le compilateur.

Vous pouvez afficher vos préoccupations sous forme de commentaires sur des lignes particulières et mener des discussions à leur sujet. Il peut faire la même chose avec votre code. La discussion reste centrée sur les modifications de code proposées spécifiques, et non sur les performances ou la compétence de quelqu'un en général.

Même les brillants ingénieurs de mon entreprise sont reconnaissants lorsque les critiques de code saisissent des fautes de frappe ou les forcent à rendre les choses plus claires. Il est tout à fait normal que les nouvelles recrues exigent plus d'itérations. Au fil du temps, vous commencez à résoudre par réflexe le type de problèmes qui, selon vous, attireront les commentaires avant de poster un diff. Obtenir un pourcentage plus élevé de vos différences au premier essai est la façon dont vous savez que vous améliorez.

Je ne repousse pas constamment le code sur ce qui pour un novice peut sembler être un détail mineur, ce qui peut être assez frustrant, mais je crains aussi que le fait d'être trop «doux» n'empêche pas le gars d'apprendre à faire certaines choses.

Ce sont à la fois des possibilités réelles 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 d'extraction ou de révision de code et que cela semble être le cas, je vous recommanderais de noter les éléments "non critiques" ou "préférés".

Si vous voyez un PR dans un état similaire à ce que vous décrivez, avec quelques problèmes stylistiques mineurs ou nécessitant une refactorisation non critique, laissez un commentaire, mais n'hésitez pas à l'approuver. Dire quelque chose comme: "Dans le futur, essayez peut-être d'éviter les noms de méthode comme celui-ci au profit de quelque chose comme descriptiveMethodName", enregistrez votre opinion sans la forcer à la changer ou à bloquer son développement.

Maintenant, ils connaissent votre préférence et, s’ils tentent de s’améliorer, ils remarqueraient avec espoir une telle situation à l’avenir. Cela leur laisse également la porte ouverte pour qu’ils le modifient réellement à ce moment-là, s’ils sont d’accord avec vous et le considèrent comme suffisamment important.

Je traite avec un développeur junior qui travaille à distance depuis une usine de codage.

Ce n’est malheureusement pas une situation idéale: un programmeur expérimenté en charge d’un programmeur débutant, avec séparation géographique. Il n’est pas surprenant qu’il y ait des tensions, mais l’écart peut être atténué.

Je suis curieux, que voulez-vous dire par "usine de codage"? Selon moi, cette terminologie dénote une attitude troublante qui pourrait exacerber certains des problèmes de gestion que vous avez mentionnés.

… Violation de la SRP, des objets divins, noms non significatifs de méthodes ou de variables; Je montre ce qu'il doit réparer et j'essaie d'expliquer pourquoi c'est faux.

Le problème, je pense, est que votre développeur junior vomit du code sans avoir passé par un processus de conception approprié. En tant que gestionnaire et développeur principal, vous n’êtes pas en mesure de fournir des conseils et d’enseigner de bonnes habitudes en matière de développement de logiciels. Vous pouvez empêcher la création d'un mauvais code si vous travaillez d'abord ensemble pour dessiner un contour. Cela serait préférable à la critique et à la réécriture du code une fois qu’il a été produit, en termes d’efficacité et de moral.

Vous devrez probablement réajuster votre flux de travail. On dirait que vous attendez actuellement de lui qu'il vous livre des produits. Vous avez besoin d’une collaboration plus étroite afin de pouvoir vous guider à chaque étape du développement. Parlez de la conception et de l’interface avant que le codage ne commence. Pendant le codage, effectuez des points de contrôle plus fréquents pour détecter les problèmes plus tôt. Si possible, essayez de programmer en binôme, via le partage d'écran avec un canal audio.

Tout cela demandera plus d’efforts de votre part, mais cela en vaudra probablement la peine, compte tenu de la relation problématique que vous entretenez actuellement.

S'il s'agit d'une violation des normes de codage, montrez-lui où il se trouve pour qu'il le sache. Si vous devez continuer à lui montrer la même erreur, vous pourriez avoir un problème avec quelqu'un qui ne peut pas se conformer aux règles ou qui refuse de le faire. N'utilisez pas votre temps libre pour réparer les erreurs. Cette personne devrait corriger ses propres erreurs pour ne pas les refaire.

Toujours leur dire ce qu'ils ont bien fait et comment ils peuvent améliorer la prochaine fois. Nous pouvons toujours nous améliorer dans certains domaines. La rétroaction est essentielle pour devenir meilleur à tout.

Une autre idée pour traiter «trop de critiques» est de faire une tâche par vous-même de temps en temps, et de laisser le développeur junior faire une révision de code pour vous. Cela présente au moins deux avantages:

• ils peuvent apprendre comment faire les choses.
• dans les cas où il existe plusieurs bonnes solutions ou noms de variables, j'accepte les approches différentes mais (presque?) tout aussi bonnes. Lorsque je répare mon code à cause des commentaires de quelqu'un, je montre aux gens qu'ils sont respectés et que les critiques ne concernent que du code, quel que soit l'auteur.