Question:
Comment puis-je amener un nouveau développeur à améliorer considérablement son code?
mtw
2020-07-14 23:45:57 UTC
view on stackexchange narkive permalink

Je suis responsable technique et nous avons une recrue récente qui est très inexpérimentée. Il est également très opiniâtre et fier pour un débutant et son style de code diverge trop de l'équipe. Mais il produit toujours du code de mauvaise qualité par rapport aux autres employés.

Ce n'est pas un problème, cependant: je suis censé attraper ces problèmes et lui apprendre à s'améliorer dans les révisions de code, les sessions de rétroaction, etc. Le problème est: quand je révise son code, je dois laisser trop de commentaires au point que j'en fais trop. Quelques fois, j'ai laissé glisser certains problèmes, mais cela finit toujours par coûter du temps à un autre développeur (ou au mien).

J'ai également essayé des sessions de commentaires en tête-à-tête pour éviter les critiques publiques, mais cela n'a pas abouti , car le développeur essayait de justifier chaque élément de retour au point de faire dérailler la session.

Quelle est la meilleure façon de gérer cela? Je reçois de bons commentaires de la part de l'équipe concernant les critiques et j'évite certains problèmes de production, mais je me sens comme le "mauvais flic" chaque fois que j'entre dans ses pull requests.

Combien de développeurs y a-t-il dans les revues de code?Je commence toujours une révision de code en récitant les règles de base, par exempletraiter la critique de manière abstraite;rendez-le impersonnel.Lorsque d'autres développeurs subissent l'évaluation du code, assurez-vous que le nouveau développeur critique également les personnes les moins expérimentées.Cela aidera le nouveau développeur à converger vers les attentes un peu plus facilement que les 1 contre 1 sans fin.
Avez-vous envisagé des outils automatisés pour vous aider?Si les problèmes sont bien définis, il existe de nombreux outils qui peuvent automatiquement signaler les problèmes.Le développeur peut avoir des opinions contradictoires sur celles que vous avez laissées glisser ou manquer, "mais ce n'était pas un problème la dernière fois - pourquoi dites-vous que c'est maintenant".Il est difficile de connaître les problèmes exacts, mais au moins de cette façon, ils peuvent obtenir des commentaires instantanés et potentiellement résoudre de nombreux problèmes avant de les voir.
_Surtout_ en ce qui concerne le "style de code", avoir des contrôles automatisés tels que Checkstyle est une bonne idée _ même avec des développeurs expérimentés_.
Pour les problèmes soulevés lors de la révision du code, s'agit-il de corrections objectives clairement définies ou de quelque chose de subjectif qui est un style personnel?Si c'est objectif, ce développeur a-t-il accès à une documentation appropriée de ce que l'on attend de lui?Quelques échantillons, certains moins graves, certains des plus graves, et nous pouvons mieux évaluer ce qui est examiné.
+1 pour l'analyse automatisée du code.Nous avons évacué le processus de révision du code en déléguant la première exécution à Sonar.Corrigez les indicateurs générés automatiquement, puis nous les examinerons.
Avez-vous impliqué la direction?Quelles sont les attentes fixées par son supérieur concernant le respect de la norme commune?Quelles sont les attentes concernant le respect des révisions de code et l'ancienneté des postes?Ces choses devraient être explicitement convenues avant que le nouveau développeur ne commence à coder.
Avez-vous essayé de lui demander ce que vous allez souligner dans son code?
"Êtes-vous prêt à écrire un code acceptable pour votre employeur, que vous l'aimiez ou non?"Si oui, "Bien, veuillez agir en fonction des commentaires que vous recevez."Si non, suggérez le travail indépendant comme cheminement de carrière plus approprié et rapportez-le aux RH / à votre patron.
@EliottRobson, nous avons de nombreux outils automatisés, y compris des règles de linter personnalisées, des outils tiers.Les principaux problèmes sont l'introduction de bogues, les problèmes de sécurité, les pratiques de dénomination des variables étranges, les tests mal écrits et la suringénierie.
@mtw "Pratiques étranges de dénomination des variables, tests mal écrits et suringénierie" J'ai exactement le même problème.Mais un peu pire parce que je ne suis qu'un développeur senior.
En tant que développeur qui occupe un rôle senior / principal depuis plus de 10 ans, la chose la plus inquiétante que vous avez mentionnée est que vos efforts pour donner des commentaires ont été vains.On dirait que le problème n’est pas un manque d’aptitude, mais un manque d’humilité.Aucun processus automatisé ou documenté ne peut résoudre ce problème.Je préfère un développeur avec une aptitude moyenne et une volonté d'accepter des suggestions plutôt qu'un développeur avec une aptitude supérieure à la moyenne et qui ne veut pas admettre avoir commis une erreur.Ce dernier m'a causé plus de problèmes dans notre environnement de production que le premier.
Une chose à propos de l'apprentissage du professionnalisme dans n'importe quel travail est qu'il ne s'agit pas de vous, et parfois les décisions qui ne sont pas optimales pour vous sont bonnes pour l'organisation.Vous ne rendez pas service à cette personne en ignorant le méta-problème ici: disons que vous la convaincre que votre style est "correct".Il / elle va juste entrer dans un autre combat avec le prochain critique au prochain travail.Concentrez-vous sur l'angle du professionnalisme, c'est-à-dire "vous occuperez un certain nombre d'emplois au cours de votre carrière dont la plupart auront * si vous avez de la chance * un guide de style en interne et vous devrez vous y adapter à plusieurs reprises".
@RicardovandenBroek, c'est aussi ce qui m'inquiète le plus.Si c'était un développeur très expérimenté avec la même attitude, j'aurais probablement les mêmes problèmes.
Il existe une solution simple: n'embauchez pas ce genre de travailleur!
@David Je suis d'accord avec votre point de vue.Malheureusement, il a été embauché par mon supérieur, mais s'il s'était comporté lors de l'entrevue comme il se comporte au travail, j'aurais certainement signalé sa candidature.Je suis tout à fait d'accord pour avoir des juniors dans l'équipe, mais s'ils ne sont pas enthousiastes à l'idée d'en savoir plus ou n'acceptent pas les commentaires, alors ils ne valent pas la peine de les avoir dans l'équipe.
Treize réponses:
#1
+55
Koenigsberg
2020-07-15 03:35:09 UTC
view on stackexchange narkive permalink

Être un "mauvais flic"

Comme mentionné précédemment, la voie à suivre est de se détacher ou de se détacher de toute autre personne des problèmes à soulever. Cela signifie:

  • Vos règles doivent être claires et écrites, que ce soit dans un wiki, un guide de style, des documents d'entreprise, tout ce que vous utilisez. Ce matériel doit être accessible au développeur en question.
  • Lorsque vous signalez des erreurs dans une critique, n'utilisez pas de phrases qui vous impliquent de quelque manière que ce soit. Au lieu de cela, transférez le blâme sur vos documents, tels que le guide de style et sur vos processus en général. Un exemple de ceci peut être, "Ligne X: Selon le styleguide [link], les variables membres statiques doivent suivre le modèle Y."

Vous ne pouvoir éviter complètement le sentiment de mauvais flic , cela fait partie des critiques. Cependant, avec un ton prudent, vous pouvez établir une culture de révision, où il est clair que ce n'est pas un développeur qui est mis en cause, mais seulement le code lui-même. Il doit être compris par toutes les parties qu'un avis ne consiste pas à critiquer une personne ou son travail, mais simplement à améliorer le code et donc votre produit.

Assigner des tâches appropriées

Ceci est probablement mon point le plus important et celui qui, je pense, justifie ma réponse en premier lieu, car il y a des redondances dans toutes les réponses publiées:

Une autre réponse de @ Ertai87 mentionne que corriger toutes les erreurs mineures est épuisant, je assumer à la fois pour le critique et pour le réviseur. Vous mentionnez également qu'il y a tellement de choses à corriger, que tout l'exercice déraille quelque peu. La réponse à laquelle je fais référence indique alors de se concentrer sur les problèmes majeurs et d'ignorer les problèmes mineurs.

À mon avis, ce n'est pas la bonne approche.

Lorsque les tâches résolues par le développeur en question sont tellement complexes que leur examen se transforme en une entreprise énorme, alors je veux dire que ces tâches sont trop importantes pour le développeur en question. Ils ne sont pas prêts et doivent se voir attribuer des tâches plus petites et commencer par les choses mineures. Cela signifie, attribuer par exemple des corrections de bogues qui ne viennent vraisemblablement qu'avec quelques lignes de code, seulement des fonctionnalités très mineures et d'autres problèmes du genre. Sinon, vous passerez une tonne d'absurdités dans votre base de code parce que vous êtes tellement occupé à corriger leurs erreurs majeures que vous ne pouvez pas vous permettre de corriger toutes les bêtises mineures. En fin de compte, ce sera probablement du temps passé par d'autres employés, qui finissent par réparer toutes ces choses lorsqu'ils travaillent à leur tour sur les mêmes passages de code.

Vous ne devriez pas vous attendre à ce que votre junior soit au même niveau que tout le monde sinon, car le processus d'amélioration doit être progressif. Pourtant, ils sont des employés, donc vous pouvez vous attendre à ce qu’ils apportent de la valeur à l’entreprise, même si cette valeur est relativement mineure et ne s’accompagne qu’au fil du temps. Alors, attribuez-leur des tâches plus petites et laissez-les commencer par les bases. Plus ils s'améliorent, plus leur domaine de responsabilité peut devenir étendu et leurs tâches peuvent également prendre de l'importance.

Posez-vous la question. Avec le temps passé à corriger le code de ce développeur, combien de temps en comparaison auriez-vous passé à le faire vous-même?

Distribuer des critiques

En tant que chef d'équipe, il n'est pas écrit dans le marbre que vous doivent revoir tout le code. Les examens peuvent être effectués par tous les employés expérimentés, vous avez la possibilité d'utiliser cette tactique. Une manière courante de procéder consiste à disposer d'un ensemble de réviseurs et d'un créneau horaire, par exemple une fois par semaine, lorsque les avis sont en cours de traitement. Pendant ce temps, tous les membres de l'ensemble doivent examiner les problèmes en attente d'acceptation / de rejet.

Il y a trois avantages principaux à cela:

  • La révision de code est une tâche qui demande beaucoup de concentration. Vous ne pouvez en faire qu'une partie par vous-même pendant une journée avant de commencer à transmettre des erreurs à la production. Plus de personnes sur cette tâche signifie plus de concentration en tant que ressource.
  • Quelle que soit votre expérience, il y a probablement des modèles dans votre code et des erreurs que vous répétez et dont vous n'êtes pas conscient. Cela vaut également pour vos pairs. Lorsque plusieurs personnes examinent les membres de votre équipe et les uns des autres, à tout le moins la personne évaluée peut voir d'autres modèles et d'autres moyens de résoudre le problème X. De cette façon, les connaissances sont distribuées dans votre équipe.
  • Plus il y a de personnes faire des critiques, moins une seule personne court le risque de devenir le mauvais flic .

Je dirai cependant que cela peut dépendre de l'entreprise et des processus en place. Certains lieux de travail peuvent exiger qu'un chef d'équipe approuve chaque élément de code et certains lieux de travail peuvent même le faire en raison d'une qualification spécifique que seul un expert apporte à la table. Un exemple de ceci pourrait être la sécurité dans un cadre médical. S'il n'y a pas d'exigences particulières de ce type, mais que les processus vous obligent actuellement à examiner personnellement tout le code qui va à la production, alors cela peut être soulevé avec la direction qui plaide pour une efficacité accrue de l'équipe. Vous seul saurez comment les choses fonctionnent dans votre entreprise, utilisez votre meilleur jugement pour savoir si la distribution des avis peut être réalisée sur votre lieu de travail.


Une note personnelle: lorsque nous avons commencé les révisions de code dans notre entreprise, c'était cahoteux au début aussi, car il est difficile de ne pas se sentir critiqué lorsque votre demande de fusion est rejetée avec un tas de choses à corriger. À présent, l'équipe chérit les révisions de code. Personnellement, j'ai appris beaucoup en faisant réviser mon code, tout comme mes pairs.

Sur le comportement défensif

Il y a certaines choses dont on peut discuter et d'autres qui ne nécessitent pas de débat. Discuter de telle ou telle architecture n'est pas rare. Ce faisant, il est important d'avoir une bonne raison pour laquelle vous voulez changer l'implémentation X en implémentation Y. Il ne suffit pas de dire "c'est mieux" . Bien sûr, vous pouvez suivre la voie faisant autorité, mais cela risque de démoraliser et de montrer un manque de perspicacité. D'un autre côté, lorsque votre équipe a développé votre guide de style, je m'attendrais à ce que vous ayez réfléchi à la raison pour laquelle vous avez décidé de faire la chose X de la manière Y. Ces choses ne devraient pas aboutir à des débats interminables à chaque fois, du moins si le consensus de l'équipe sur la question n'a pas changé.

Dans l'ensemble, le comportement défensif n'est pas un problème aussi simple ou rapide à résoudre d'après mon expérience. Je suggère de faire des entretiens en tête-à-tête de temps en temps. Semblable à des évaluations de performance, mais destiné à être une discussion non interrogative entre deux membres de l'équipe, plutôt qu'un patron donnant l'entreprise à son subordonné. C'est un moment où vous pouvez partager vos griefs avec les performances de l'employé en suggérant des améliorations. Il est également important d'écouter leur côté. Sont-ils satisfaits de ce qu'ils font? Si non, quels sont les problèmes dans leur esprit? Comment peut-on les résoudre?

Cela étant dit - si toutes ces tentatives ne portent pas leurs fruits, alors la voie faisant autorité peut être tout ce qui reste. Dans ce cas, expliquez au développeur que ses performances ne sont pas satisfaisantes, aussi difficile que cela puisse paraître. Il s'agit essentiellement d'un avertissement et à ce stade, j'envisagerais de laisser partir cette personne.

Je comprends que cela peut sembler dur, mais en fin de compte, chaque employé doit apporter de la valeur à la table. La valeur d'un junior au début peut être à peine au-dessus de zéro, cela peut même être un investissement dans la productivité future, sans aucun gain immédiat. Cependant, si le temps passe et qu'aucune amélioration n'est constatée, alors l'entreprise gaspille de l'argent et l'employé n'est pas la bonne personne pour vous.

Il y a cependant beaucoup de choses à essayer avant que cela ne se produise, certaines mentionnées ci-dessus . Vous devriez vous demander si vous pouvez améliorer votre communication avec cet employé et partir de là. Est-ce que vous formulez des choses qui les forcent à adopter une position défensive? Si le développeur s'avère être un atout pour l'entreprise qui n'a été entravé que par une mauvaise communication entre eux et vous, alors tout le monde y gagne une fois que cela est reconnu et résolu.


Autre note personnelle: I J'ai déjà travaillé et enseigné à des juniors de la vue dans mes dernières entreprises - principalement des étudiants en licence et en master, faisant les premières étapes du codage pour des applications du monde réel, mais aussi des codeurs autodidactes ainsi que des juniors avec un autre formation. Une chose que de nombreux étudiants apprennent après avoir franchi cette étape, c'est que les compétences techniques, aussi bonnes que vous soyez, font partie d'une équation plus large. Les compétences générales sont plus importantes et doivent être rattrapées si nécessaire.

De nos jours, nous filtrons les candidats en évaluant leur caractère plutôt que leurs compétences techniques. Ils ont une formation similaire et nous nous en remettons à ce fait. La compatibilité de la personnalité est cependant très importante, car une pomme pourrie peut empoisonner tout le panier. Jusqu'à présent, principalement en promouvant une culture d'entreprise très accueillante, nous avons pu intégrer tous nos étudiants et chacun d'entre eux est finalement devenu un atout, mais nous prenons notre temps avec eux et n'affectons pas quelqu'un qui apprend le cordes tâches géantes. Comme dit, les progrès sont progressifs.

J'espère que ce mur de texte vous aidera d'une manière ou d'une autre. Bonne chance!

Excellente réponse!Je recommanderais également ce livre, Code Complete 2, pour vous aider à créer des listes de contrôle et des guides de style.https://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/
+1 bien pensé et souligne à quel point l'équipe dans son ensemble est importante, les compétences peuvent être améliorées facilement, la personnalité est beaucoup plus difficile.
En ce qui concerne les lieux de travail où un responsable est tenu de procéder à un examen: il est généralement toujours possible que quelqu'un d'autre dans l'équipe l'examine d'abord, pour la conformité générale et la qualité, puis une fois qu'il est conforme à une norme acceptable, le responsable de l'examenl'expertise spécifique est.Dans certains cas, cela pourrait encore impliquer de tout examiner en détail, mais cela réduirait au moins la charge de travail de la tête.
Ayant moi-même traité ce problème à plusieurs reprises, je soutiens particulièrement l'idée de bien répartir les tâches.Quelqu'un qui ne comprend pas encore comment l'équipe organise le code, les normes locales, les conventions de formatage, etc. ne devrait vraiment pas écrire (pour les instances) des modèles et des classes entiers.Ou ils devraient le faire en sachant qu'ils doivent imiter les modèles et les habitudes présentés ailleurs, car en ce qui concerne le code, le plus important est la cohérence.
Un guide de style n'a pas besoin de justification au-delà, "Nous avons fait un choix arbitraire et nous nous en tenons à lui pour maintenir une base de code cohérente."Bien sûr, avoir une justification appropriée est préférable, mais une partie substantielle de la motivation pour avoir un guide de style est de rendre le code cohérent.
#2
+48
Llewellyn
2020-07-15 00:20:56 UTC
view on stackexchange narkive permalink

S'il y a autant d'erreurs dans le code, peut-être qu'une révision du code est trop tard pour les rattraper. Vous devez peut-être prendre du recul. Il existe des approches alternatives que vous pouvez adopter:

  1. Formation. Cela n'a pas à être un cours. Il peut s'agir d'un livre, d'une série de vidéos, d'un site d'exercices.

  2. Conseils personnalisés. Au lieu de signaler à plusieurs reprises les mêmes erreurs dans les révisions de code, peut-être le prendre à part et expliquer les plus courantes plus en détail.

  3. Programmation par paires. Laissez-le observer quelques-uns des autres développeurs. C'est le moyen le plus rapide d'acquérir le style de code interne.

  4. Mentorat. Désignez officiellement un autre développeur comme mentor pour aider à la révision du code. Idéalement, les deux parties devraient s'entendre sur ce point.

1. oblige l'individu à _vouloir_ s'améliorer, ce qui ne semble pas être le cas ici.2. semble avoir été fait de manière excessive.3. Peut être une option mais chère.4. encore une fois - a besoin de coopération.Et vous avez oublié 5.: Laissez-le partir.
@Fildor L'idée que la programmation par paires est en quelque sorte coûteuse est une énorme idée fausse.La création de logiciels n'est pas une ligne de production où tout le monde doit être occupé et utilisé au maximum.C'est un travail de design créatif.Et les meilleurs designs viennent de la collaboration et de la communication.
@Euphoric Je sais ce que tu veux dire.J'ai déjà fait des pp.Je le fais parfois de temps en temps.Il est cher.Cela n'a rien à voir avec si ces dépenses sont justifiées ou créent un retour sur investissement plus tard.De plus, dans ce cas, pp n'aurait pas les avantages ni même l'intention que vous décrivez.Ce serait simplement du baby-sitting.Baby-sitting coûteux.
@Fildor, Il y a déjà un baby-sitting onéreux qui se passe: cela se produit uniquement pendant la révision du code lorsque le développeur pense qu'il est "terminé" et est sur la défensive de ses décisions.D'après mon expérience, plus le retour d'information est donné tôt dans le processus de développement, plus il est probable qu'il soit bien pris, donc le passage à la programmation par paires pendant un certain temps pourrait potentiellement améliorer les résultats sans prendre beaucoup plus de temps.
@ParkerCoates N'a pas contesté cela.Cela vaut peut-être la peine d'essayer.
#3
+33
Ertai87
2020-07-15 00:11:03 UTC
view on stackexchange narkive permalink

Le réviseur de code est censé être le "mauvais flic". C'est ton travail. Si vous vous sentez comme un "mauvais flic", c'est une bonne chose et vous devriez l'accepter. Cela dit ...

  1. Les développeurs juniors font beaucoup d'erreurs. Les signaler tous est épuisant, frustrant et démoralisant. S'ils par exemple nommez une variable incorrectement, ou utilisent une recherche linéaire au lieu d'une recherche binaire pour un ensemble de données suffisamment petit, ou n'ont pas écrit un test unitaire pour un morceau de code qui, selon vous, fonctionne correctement, cela ne vaut probablement pas la peine d'être discuté. Économisez votre énergie pour les problèmes graves, au moins lors du premier passage ...

  2. Effectuez plusieurs passes. Dans la première passe, examinez uniquement les problèmes les plus critiques. Ensuite, laissez le développeur résoudre ces problèmes et passez aux problèmes les plus graves suivants. Vous voudrez peut-être faire 3-4 passes sur un PR pour résoudre tous les problèmes. Trop de problèmes sont démoralisants et déroutants à lire.

  3. Faites remarquer quand le développeur fait quelque chose de cool que vous aimez. Vous pouvez également être encourageant dans votre révision de code si vous ajoutez un commentaire comme "oh, c'est une bonne façon de faire ce bon travail!" de temps en temps.

  4. Reconsidérez si vos pratiques de codage sont peut-être trop strictes. Si vous avez quelque chose comme "chaque variable int doit se terminer par le mot Int", c'est peut-être une restriction stupide que vous devriez envisager de relâcher. Combien de vos règles sont conformes aux normes de l'industrie et combien sont ésotériques?

  5. Si tout le reste échoue, vous devez parfois baisser les bras. Vous êtes le réviseur de code. Le code n'est pas fusionné sans votre avis. Vous êtes aussi le senior de l'équipe, c'est le junior. Il arrive un moment où vous dites simplement "Je suis meilleur que vous, faites ce que je dis". Essayez de ne pas retirer la carte d'ancienneté trop souvent ou elle deviendra toxique et démoralisante, mais vous pouvez la retirer de temps en temps lorsque vous en ressentez le besoin. Si vous retirez la carte d'ancienneté, assurez-vous que vous êtes sûr à 100% d'avoir absolument raison. Si vous retirez la carte d'ancienneté et que vous vous trompez, vous allez perdre beaucoup de visage, à la fois avec ce développeur, mais aussi avec votre patron et votre équipe. Personne n'aime le gars qui gémit et se plaint, puis quand il arrive à ses fins, cela fait planter la production.

D'ailleurs, le fait de mal nommer une variable pourrait être encore pire si cela induit en erreur un responsable sur ce qui se passe dans le système.
@Kevin Mais utiliser une recherche linéaire pour un ensemble de données suffisamment petit n'est pas un problème ... C'est plus facile à implémenter, plus facile à vérifier, plus facile à comprendre (pour les réviseurs et les futurs lecteurs), et n'a peut-être pas besoin d'être testé.Vous avez échangé une efficacité marginale qui n'a peut-être même pas d'importance pour une tonne de temps gagné.$$$.Économie.En outre, cela pourrait être une solution plus rapide pour certains `n
Une chose: je recommanderais de prendre du recul sur le `` faire plusieurs passes '', et d'abord savoir si le junior a un problème avec de nombreuses remarques à la fois, ce qui le fait se sentir dépassé, ou si les passes multiples donneraient au junior le sentiment que ``ce n'est jamais assez bon '' ou ennuyé d'avoir à faire autant de va-et-vient (je tombe définitivement dans cette dernière catégorie, je serais énervé si je découvrais que quelqu'un savait déjà que quelque chose n'allait pas mais l'a gardé pour après 3 aller-retour - et-forths alors que j'aurais pu le réparer la première fois aussi).C'est une bonne stratégie pour le premier type de personnes, pas pour le second.
#4
+25
Kevin
2020-07-15 00:46:29 UTC
view on stackexchange narkive permalink

La réponse est un peu méchante, mais ... tout s'enchaîne sur le bateau "tout faire pour l'application de la loi" , autant je déteste voir les choses de cette façon.

Je veux dire, vous avez dit:

  • Il "produit du code de mauvaise qualité" (même en dehors des différences de style)
  • Les choses que vous avez déjà laissées slide ont coûté du temps à vos autres développeurs.
  • Il est "très inexpérimenté".
  • Il a des opinions et n'est pas réceptif au changement.

La raison Je signale que ces choses sont ... et si vous disiez soudainement: "Vous savez quoi? Ce type ne peut pas déplacer aucun de son code vers la production avant que le code complètement est conforme à nos standards. "

Ce n'est pas comme si le développeur produisait des tonnes de code incroyablement productif et que vos standards seraient perçus comme agaçant et freinant les résultats de l'entreprise. Ce n'est pas comme si le développeur était réceptif au changement non forcé, et que ce problème disparaît après plusieurs mois. Ce n'est pas comme si le développeur publiait du code qui ne coûte pas du temps de maintenance inutile à votre autre développeur en raison des écarts de normes.

... et aussi triste que cela soit? Ce n'est pas comme si le développeur était un atout extrêmement précieux pour l'entreprise. C'est exactement ce qui se passe lorsque vous combinez "Junior inexpérimenté" avec "Pas disposé à apprendre ou à changer".

À cause de tout cela, votre meilleur pari est probablement simplement de tracer une ligne et de dire: " pour promouvoir le code à moins qu'il ne soit entièrement conforme aux normes. Point final. Vous devrez soit commencer à suivre les normes lorsque vous composerez votre code, soit commencer à prévoir du temps pour le réécrire avant de pouvoir le mettre en production. " Et ne laissez rien glisser.

Le développeur va probablement détester cela. Peut-être finiront-ils par améliorer et écrire du code de qualité. Peut-être pas. Mais ... c'est la partie la plus triste. Un junior inexpérimenté qui refuse d'apprendre ou de changer en décidant de quitter votre groupe n'est pas si terrible qu'un résultat.

EDIT: Oh, autre chose que j'ai oublié d'ajouter: c'est un junior "très inexpérimenté". Même si je ne vais certainement pas dire: «N'écoutez jamais les juniors parce qu'ils n'auront rien à apporter», il n'y a rien de mal à dire: «Écoutez, j'en sais beaucoup plus à ce sujet, et je vous le dis : c'est ainsi que fonctionne notre groupe, et c'est la norme. Vous devez modifier votre code pour qu'il corresponde », puis passer au numéro suivant sur la révision du code.

#5
+7
Matthew Gaiser
2020-07-15 00:50:07 UTC
view on stackexchange narkive permalink

Combien de ces règles de style sont réellement écrites?

Mon organisation procède (parfois) à une révision du code, mais l'un des problèmes est que nous ne suivons aucune règles concernant la paternité du code. Vous pouvez obtenir des commentaires entièrement différents (et souvent contradictoires) en fonction de la personne qui effectue la révision. Cela n'aide pas non plus que la plupart du code ait été écrit avant l'arrivée de tous les membres de l'équipe actuelle, ce qui signifie qu'aucun d'entre eux ne s'aligne non plus et l'utilisation du code antérieur comme exemple n'a pas fonctionné.

Pour la révision du code sur le style / organisation pour travailler, des règles claires doivent exister. Il est incroyablement frustrant d'essayer de respecter des règles qui sont quasi "juste connues" au sein de l'équipe. Imaginez que vous essayez de reproduire un tableau tout en le visualisant à travers le brouillard.

Dans le cas de votre développeur junior, vous pouvez simplement lui dire que le code doit "adhérer au guide de style" et le lui renvoyer à la place de faire un barrage de commentaires répétés.

Vous ne devez pas arrêter les révisions de code, mais vous devez également vous assurer que le nouveau développeur est dans une position raisonnable pour savoir quelles sont les règles.

C'est très bien si les problèmes de révision de code sont "utiliser la casse camel" ou "mettre en retrait en utilisant des tabulations au lieu d'espaces".Mais si le développeur a beaucoup de bogues ou de code qui n'inclut pas la vérification des erreurs, cela ne peut pas être couvert par un guide de style.
Les bogues d'@DaveG ne le seraient pas, mais les tests unitaires pour vérifier les bogues le seraient.Les règles de gestion des erreurs figureraient également dans un tel guide.Les guides de style de code sont probablement plus précisément appelés directives de développement.
Plutôt que de les écrire * vous-même *, vous pouvez également simplement utiliser certaines normes de codage couramment utilisées (avec des ajustements mineurs, si vous le souhaitez).Cela pourrait également aider les développeurs expérimentés à rejoindre votre équipe, car ils sont plus susceptibles d'avoir déjà utilisé ces normes et il est donc moins probable qu'ils ne soient pas d'accord avec un point donné.
L'étape suivante consisterait à utiliser des outils automatisés pour analyser que le code respecte les normes (par exemple, un linter).Être capable d'exécuter quelque chose qui produit une liste de problèmes dans un code est beaucoup plus facile que de trouver ces problèmes vous-même en fonction de ce que dit un document de 10 pages.Certains de ces outils peuvent également identifier certains bogues.
Modification suggérée: "Combien de ces règles de style sont réellement écrites?"-> "En fait, écrivez ces règles de style".La déclaration souligne que vous recommandez quelque chose, alors que la question semble plus conversationnelle ou comme si vous demandez des éclaircissements.
«Notez tout» est la raison pour laquelle les systèmes juridiques sont si compliqués et enclins à des trous en boucle.(Dois-je écrire "les noms de variables doivent être en anglais"? Qu'en est-il des commentaires? Oups, nous avons maintenant une faille où les noms de fonction peuvent toujours être en klingon, ou quelqu'un a nommé une variable very_long_variable_name_definately_in_English.) C'est pourquoi nous avons la common law,également connu sous le nom de code précédemment écrit.Si personne dans votre équipe ne suit le code précédemment écrit et que tous donnent des commentaires contradictoires, vous n'avez aucune loi - vous avez juste de l'anarchie, et c'est un problème différent.
Les systèmes juridiques @user3067860 doivent gérer les personnes qui tentent activement de les enfreindre.Assumant un effort de bonne foi de la part des développeurs, les directives de développement n'ont pas besoin d'être aussi longues.
@MatthewGaiser C'est mon argument, car je vois beaucoup de réponses disant qu'il ne doit pas y avoir assez de règles écrites explicitement.
OP ici.Le "style de code" ne s'applique pas uniquement à la structure superficielle.Nous avons des linters.Je suis également d'accord avec @user3067860 pour dire que nous ne devrions pas être obligés d'écrire chaque chose pour qu'une personne sur vingt ne la casse pas.
@mtw J'ai vu du code qui équivaut à "Je suis né très jeune" ... techniquement correct, mais ne le faites pas non plus.
#6
+3
Heinzi
2020-07-15 13:16:45 UTC
view on stackexchange narkive permalink

J'ai également essayé des sessions de commentaires en tête-à-tête pour éviter les critiques publiques, mais cela n'a pas fonctionné, car le développeur essayait de justifier chaque commentaire au point de faire dérailler la session.

Il semble que vos styles de travail sont incompatibles : vous voulez qu'il travaille d'une manière particulière (ouverture aux retours, code de haute qualité, accent sur la maintenabilité, ...), et il veut travailler différemment (appelons-le "codage de cowboy solitaire"). C'est frustrant pour les deux parties.

Pour emprunter la terminologie du jeu de rôle: Vous avez besoin d'une session zéro. Asseyez-vous, expliquez ce que l'on attend de lui à long terme (ouverture au feedback, code de meilleure qualité, volonté de changer, etc.), et déterminer si c'est quelque chose qu'il veut.

  • S'il le fait ... expliquez que vous êtes ici pour l'aider à devenir ce futur moi qui convient bien à votre entreprise, et que beaucoup d'apprentissage et de changement seront nécessaires. Il doit s'engager à atteindre cet objectif et accepter que les revues de code soient un outil pour y arriver. Plus il reçoit de commentaires sur les révisions de code, plus il peut s'améliorer et atteindre cet objectif.

  • S'il ne le fait pas ... eh bien, ce sera peut-être mieux pour les deux parties se séparer à l'amiable. Les programmeurs sont actuellement très demandés, il ne devrait donc pas avoir de problème pour trouver une entreprise où une approche moins structurée du développement logiciel est appréciée (il y a beaucoup de questions ici sur The Workplace.SE se plaignant de ces entreprises).

Je pense que vous devez avoir un peu d'expérience avant que votre "style de codage" puisse être raisonnablement considéré lorsqu'il est mesuré par rapport à une base de code existante.Même considérer le style ici, c'est vraiment mettre la charrue avant les boeufs, considérant que la question concerne un développeur junior qui refuse fondamentalement d'apprendre.
@kungphu: Je ne voulais pas dire "style de codage" dans le sens de "où mettre vos accolades", je veux dire le "style de développement logiciel" plus général, disons "codage de cow-boy solitaire" par rapport à un processus de développement axé sur la maintenabilité du codeet une forte culture de rétroaction.Le junior semble préférer le premier (que ce soit par inexpérience ou par conviction n'a pas d'importance, s'il ne veut pas changer), alors que l'entreprise de l'OP exige ce dernier.Je conviens que l'expression «style de codage» est trompeuse ici, j'ai changé cela.
OK, cela a du sens.Bien qu'il semble que cette situation soit moins le fait que le nouveau développeur préfère quelque chose en particulier que le fait d'être fondamentalement ignorant de beaucoup de choses que les développeurs expérimentés (et quiconque a travaillé avec succès en équipe) prendraient pour acquis ... pour moi, leLe principal point à retenir de cette question était qu'ils avaient embauché un enfant mais n'étaient pas prêts à en élever un.J'espère que la société / le département saisira cette opportunité avec cette embauche s'ils ont l'intention de continuer à embaucher des développeurs juniors, plutôt que de le congédier pour quelque chose qu'ils auraient vraiment dû voir venir.
#7
+2
Polygorial
2020-07-15 15:06:21 UTC
view on stackexchange narkive permalink

Il y a beaucoup de bonnes réponses à cette question, je vais ajouter quelques réflexions que je n'ai pas vues dans les autres réponses.

  • Vos normes de codage s'écartent-elles beaucoup de les normes de la langue? Si c'est le cas, il sera plus difficile d'amener les développeurs à le suivre, en particulier les nouveaux développeurs qui ont du mal à comprendre simplement le code.
  • Si vos normes de codage ne s'écartent pas beaucoup des normes linguistiques, vous pouvez pointer vers il s'agit des normes linguistiques, et ce sera la même chose pour la plupart des entreprises.
  • Utilisez-vous des outils pour effectuer automatiquement autant de révision que possible? Le formatage des modèles dans l'éditeur résout beaucoup. L'analyse de code statique aide beaucoup plus.
  • Les révisions de code visent à améliorer le code maintenant et à l'avenir. Vous devez vous assurer qu'il est possible pour le développeur d'apprendre. Une façon est de donner du crédit quand quelque chose est bon. Un autre pour laisser le développeur examiner le code des autres, de cette façon, il est possible de voir du bon code. Notez que je ne suggère pas nécessairement que le développeur junior soit le seul évaluateur.
  • La plupart des gens tout droit sortis de l'université / peu importe ce qu'ils ne savent pas à quel point ils ne savent pas, et pensent qu'ils savent tout . Bien que cela puisse être frustrant, c'est comme ça, et ce sera mieux à mesure qu'ils apprendront qu'ils ne savent pas. L'attitude s'améliorera en même temps.
  • Je pense que vous devez vous attendre à ce que certains codes ne soient pas à la hauteur de toutes vos normes, en particulier pour un développeur junior. Concentrez-vous sur la mise aux normes des pièces importantes et ajoutez des commentaires supplémentaires le cas échéant. De cette façon, le développeur n'aura pas l'impression que rien n'est assez bon et abandonne.
OP Here: Nos normes de code sont à peu près dérivées de ce que les grands acteurs de l'industrie utilisent.Les écarts sont principalement dans des choses étranges qui ne peuvent pas être attrapées par les linters et autres outils.Je vois honnêtement cela comme une tentative de conformité malveillante.
#8
+1
nick012000
2020-07-15 11:58:12 UTC
view on stackexchange narkive permalink

Mettez-le sur un plan d’amélioration des performances.

On dirait qu’au moment où il produit une valeur négative pour l’entreprise - il reçoit un salaire pour perdre du temps. d'autres développeurs plus expérimentés. De toute évidence, ce n'est pas une position viable pour lui pour l'entreprise, et quelque chose doit changer. En conséquence, il peut être judicieux de formaliser cela avec un plan d'amélioration de la performance qui comprend des jalons et des objectifs concrets à atteindre, afin qu'il puisse soit améliorer ses performances pour être un avantage net pour l'entreprise, soit être renvoyé pour un motif valable. afin qu'il ne nuit plus à ses performances.

Ce serait beaucoup plus raisonnable s'il n'était pas un employé nouveau, "très inexpérimenté". Celui qui l'engageait savait qu'il était inexpérimenté.La question se lit beaucoup plus comme si le processus de recrutement avait abouti à l'intégration d'un développeur très junior sans fournir le contexte / la formation / le matériel appropriés nécessaires pour lui permettre de comprendre les normes et les attentes.Un PIP peut être décourageant et démoralisant même pour une personne expérimentée;pour un nouvel employé, cela pourrait ruiner toute bonne volonté, enthousiasme ou rapport.
Je n'ai pas encore vu une seule instance où un PIP fournit une valeur réelle à un employé.Ce n'est rien de plus qu'un moyen d'essayer de se soustraire au paiement du chômage lorsqu'un employé est licencié.
#9
+1
gnasher729
2020-07-15 12:56:34 UTC
view on stackexchange narkive permalink

Je dirais que vous lui confiez une petite tâche, puis vous examinez le résultat et le laissez retravailler ce qu'il a fait jusqu'à ce que vous en soyez satisfait. S'il essaie d'argumenter et qu'il a tort (c'est important évidemment), alors vous lui dites qu'il devrait savoir ce qui ne va pas, et lui demandez pourquoi il pense qu'il doit défendre l'indéfendable. S'il existe des styles de codage auxquels tout le monde adhère, dites-lui d'y adhérer. Attention: j'ai quelques habitudes de codage parce qu'elles sont meilleures, certaines parce que la cohérence est importante dans certains cas, et d'autres habitudes de codage qui ne sont que des habitudes.

#10
+1
Christos Hayward
2020-07-15 17:01:45 UTC
view on stackexchange narkive permalink

Dans la Philokalie, il est dit que tel ou tel peut aider les gens avec tel ou tel déficit, et tel ou tel peut aider les gens avec seulement tel ou tel déficit, "mais seul Dieu peut aider les orgueilleux. / p>

La fierté est, en plus d'être un péché, une faiblesse qui met une garde de fer autour d'autres faiblesses (cf. Chesterton). Quelqu'un qui est humble et inexpérimenté peut faire des progrès constants dans son apprentissage. Quelqu'un qui vous méprise et s'exempte de toute correction a un niveau de rémunération plus élevé qu'un simple quelqu'un qui est bon, inexpérimenté à l'ancienne.

Vous avez besoin d'un humble programmeur. Mettez-le sur un plan d'amélioration des performances, comme dernière mesure de miséricorde au lieu de simplement le mettre fin (ce qui est justifié).

#11
  0
Bardicer
2020-07-15 19:47:29 UTC
view on stackexchange narkive permalink

Je n'ai vu cette option nulle part là-bas ... mais si vous n'avez pas quelque chose comme l'application automatique de linting / stylecop dans le cadre de votre processus de développement, ce serait une excellente première étape car elle capturera un grand partie des problèmes sans que quiconque ait besoin de se sentir comme un "mauvais flic".

Mettez-le dans le code dans le cadre d'une construction - si l'une des règles n'est pas respectée, comme peut-être vous attendez-vous à un espace avec un if , c'est-à-dire if (...) au lieu de if (...) ou si une variable ne doit pas avoir de trait de soulignement et doit être camelCase au lieu de PascalCase et qui casse la compilation en cas de violation ... alors s'ils enfreignent la règle et que cela explose sur eux, ils sauront ce qu'ils ont fait de mal et ce qu'ils doivent faire pour le réparer sans avoir à affecter le temps de quelqu'un d'autre.

Avec cela en place, les sentiments ou la fierté de personne ne sont blessés inutilement parce que leurs problèmes mineurs sont pris en compte par la bibliothèque d'application du style et non par une autre personne. Cela vous permettra également de vous concentrer sur les odeurs de code et les problèmes plus importants.

Quand vient le temps de jeter un œil sur leur code, si quelque chose ne va pas, appelez-le ainsi qu'une explication comme POURQUOI cela est mal fait. Attendez-vous à un certain recul, et ce n'est pas grave s'ils peuvent donner une raison valable (performances, maintenabilité, etc.) pour laquelle ils l'ont fait d'une meilleure façon. Gardez l'esprit ouvert à ce sujet. S'ils commencent à devenir trop défensifs et hérissés, dites-le aussi, mais d'une manière non combative, comme "Hé, nous sommes une équipe, nous coulons ou nageons ensemble. Je n'essaie pas de vous faire vous sentir mal 'j'essaie de vous aider à éviter les pièges dans lesquels je suis tombé dans moi-même. "

Quand quelqu'un doit être un" mauvais flic ", essayez de pousser cela sur le code sans émotion autant que possible, comme il ne le fait pas' t se soucier si quelqu'un l'aime ou non. Lorsque vous devez assumer ce rôle, soyez un "bon flic" donnant un "amour dur" au lieu d'un "mauvais flic" pur et simple.

Exactement.Et la plupart des outils d'analyse de la qualité du code (comme Sonarqube, Codacy, LGTM, etc.) vous donneront un décompte numérique des différents types de problèmes - problèmes de style, odeurs de code, vulnérabilités, etc. - qui agit comme un «score».Le développeur peut travailler seul pour améliorer son score, avant de soumettre le code pour examen.
#12
-1
virolino
2020-07-15 13:56:32 UTC
view on stackexchange narkive permalink

Le problème est le suivant: lorsque je révise son code, je dois laisser trop de commentaires au point d'avoir l'impression d'en faire trop . Quelques fois, j'ai laissé passer certains problèmes, mais cela finit toujours par coûter du temps à un autre développeur (ou au mien).

Cela signifie que le premier problème à résoudre est vous et l'entreprise. Comment? Pourquoi?

Si l'entreprise est au moins minimalement professionnelle, il devrait y avoir des directives de codage écrites formelles, des directives de conception, etc. Dans ces directives, tout devrait être classé: obligatoire, presque obligatoire (peut être ignoré par exemple seulement s'il y a de très bonnes raisons et que toute l'équipe est d'accord), facultatif. Ces consignes doivent être obligatoires et suivies par tout le monde.

Si ce qui précède est mis en œuvre et fonctionne, le nouveau gars peut simplement revoir son travail conformément aux règles, avant de le réviser. Beaucoup de choses seraient corrigées "par elles-mêmes".

Puisque nous parlons de logiciel, l'utilisation d'un outil d'analyse statique (approuvé et configuré par l'entreprise) devrait être obligatoire. Cet outil capturera un bon nombre de choses (espérons-le), et le nouveau gars peut faire beaucoup de travail de manière indépendante avant de parler avec quelqu'un d'autre.


Commentaires - avec une touche

Non seulement ses collègues devraient revoir son travail, mais il devrait aussi revoir le travail de ses collègues. Il apprendra comment fonctionnent réellement les critiques et il apprendra pourquoi certaines choses sont importantes.

Il se souviendra des critiques qu'il a formulées pour le travail de quelqu'un d'autre lorsque son travail sera critiqué.


  • Si j'étais le nouveau venu, et
  • s'il n'y avait pas de directives formelles,

alors j'aurais une position beaucoup plus forte contre vos avis:

Pourquoi votre opinion est-elle meilleure que mon opinion?

ou même mieux:

Pourquoi? Où est-il écrit?

Mise à jour: le gars le fait déjà !! (J'ai manqué cette information lorsque j'ai lu la question au départ)

J'ai également essayé des sessions de commentaires en tête-à-tête pour éviter les avis publics, mais cela n'a pas abouti, comme le développeur essayait pour justifier chaque commentaire au point de faire dérailler la session .

En l'absence de point / système de référence, toute opinion vaut toute autre opinion.

@Michael: Merci pour le commentaire.Vous avez raison, je mettrai à jour la réponse.J'avais en tête plutôt "il attrapera tout ce qu'il peut attraper".
#13
-2
Michael
2020-07-15 14:43:31 UTC
view on stackexchange narkive permalink

son style de code diverge trop de l'équipe

Je ne sais pas si vous pensez que le style est le seul / problème majeur avec son code, ou s'il est également médiocre dans d'autres moyens, mais celui-ci est facilement résoluble.

La solution est de rendre impossible l'enregistrement d'un code qui s'écarte de vos attentes. Vous n'êtes pas obligé d'être le méchant. Laissez l'ordinateur être le méchant.

La première étape consiste à codifier vos attentes. Checkstyle (un outil Java) utilise un format de style XML. Il est également extensible pour les contrôles personnalisés. Je l'ai trouvé assez bon. Vous devriez également avoir une version lisible par l'homme, de préférence avec des exemples.

Ensuite, vous voulez vous assurer que votre build échouera si un développeur s'écarte du style attendu (vous avez une construction automatisée, n'est-ce pas?). Nous utilisons le plugin Maven Checkstyle pour nos projets.

Il est plus facile de résoudre les problèmes localement que d'attendre que la construction automatisée échoue, donc je trouve qu'il est conseillé de configurer un hook de pré-validation pour exécuter le même plugin de construction , de sorte qu'il n'est pas possible (sans contourner délibérément le crochet) de pousser quelque chose qui s'écarte du style attendu.

La dernière étape consiste à s'assurer que la vie de vos développeurs ne soit pas consommée par essayer d'adhérer à ton style; vous devez distribuer des ressources pour les aider à le faire. Cette étape est importante pour s'assurer qu'ils ne vous détestent pas pour les 3 étapes précédentes. Configurez votre IDE pour qu'il corresponde à votre guide de style et exportez les paramètres, afin que votre équipe puisse les importer. Placez le fichier de paramètres dans un référentiel auquel tout le monde a accès. Si différents membres de l'équipe préfèrent des IDE différents, pensez à EditorConfig qui le fait d'une manière indépendante de l'IDE. Une fois que vous avez fait cela, adhérer au style devrait être aussi simple que de cliquer sur un raccourci clavier.

Examinez également les plugins IDE qui correspondent à l'outil que vous utilisez dans le cadre de la construction. Nous utilisons un plugin Checkstyle pour IntelliJ qui peut charger un fichier XML de style personnalisé et affichera les violations en ligne, tout comme une erreur de syntaxe.

Pour autant de violations que possible, automatisez les correctifs . Je trouve que le formatage automatique de tout le code donne souvent des résultats bizarres. Dans certains cas, comme les déclarations d'importation inutilisées, un ordinateur peut facilement les réparer lui-même avec un faible risque.



Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 4.0 sous laquelle il est distribué.
Loading...