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.

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.

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).

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.

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.

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.

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é).

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.

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.

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.