Une chose que j'ai faite lorsque je suis devenu responsable a été de créer un document sur les meilleures pratiques et les normes de codage. J'ai tout inclus jusqu'aux conventions de dénomination des variables, des objets et des procédures.

Les revues de code sont inutiles à moins et jusqu'à ce qu'un ensemble bien documenté de bonnes pratiques et procédures ait été établi.

CECI

• utilisez const au lieu de var
• indentez ceci et cette ligne avec 2/4/6 espaces
• variable que vous avez créée n'est pas utilisé
• certaines conditions ne sont pas nécessaires
• utilisez des guillemets simples au lieu de guillemets doubles, par souci de cohérence, etc.
• 1787 n'est pas un code de pays, devrait être 1

Cela pourrait être CELA

Conformément à nos meilleures pratiques, j'ai noté ce qui suit

• utiliser const au lieu de var (voir page 5)
• indenter telle ou telle ligne avec 2/4/6 espaces (voir page 32 sur les retraits)
• la variable que vous avez créée n'est pas utilisée (voir page 15 sur l'utilisation des variables)
• certaines conditions ne sont pas nécessaires (voir page 27) fort>
• utilisez des guillemets simples au lieu de guillemets doubles, par souci de cohérence, etc. (page 11, cohérence du code)
• 1787 n'est pas un code de pays, doit être égal à 1

Le fait d'avoir établi des normes élimine également vos préoccupations concernant les préjugés perçus. Tant que vous êtes cohérent, que vous maintenez des normes élevées pour vous-même et que vous avez défini des normes et des attentes, tout devrait aller bien.

Autre point, soulevé par Rhayene: si la base de code entière n'est pas encore à le point qu'il devrait être, augmenter l'ensemble de règles par étapes planifiées au fil du temps, pour amener tout le monde sous les mêmes normes. Vous obtiendrez probablement moins de refoulement de cette façon.

Comment faire des révisions de code aux personnes dont les compétences en programmation sont faibles?

Votre tâche est de réviser le code soumis, pas d'évaluer leurs compétences dans leur langage de programmation. Vous devez traiter chaque avis de la même manière, quels que soient vos sentiments personnels à l'égard du programmeur. Tant que vous êtes cohérent avec vos commentaires et corrections parmi tous les codes que vous révisez, il ne devrait y avoir aucune crainte de «cueillette» de votre part.

Les révisions de code sont l'occasion pour vous de fournir des connaissances et un aperçu du travail que vos collègues ont accompli. C'est aussi l'occasion pour vous d'apprendre d'eux. En regardant un avis comme celui-là, je recherche trois domaines.

1. Problèmes de peluchage / style -

Si vous avez un guide de style dans le l'entreprise, il devrait être accessible et idéalement appliqué avant le processus d'examen. Si des problèmes de style surviennent à ce stade, je voudrais rappeler la règle au développeur et lui demander de la garder cohérente avec le guide de style. Soulignez que le but d'un guide de style est de garder le code cohérent et facilement lisible. Si les développeurs ont des difficultés à exécuter un linter ou autre, organisez une réunion avec eux et montrez-leur. Répondez à leurs questions. Une partie de votre travail en tant que révision consiste à vous assurer que la personne est en mesure de corriger ses erreurs et de s'assurer qu'elles ne continueront pas à poser problème à l'avenir.

2. Logique problèmes -

Lorsque vous rencontrez quelque chose qui ne semble pas à sa place, soyez gentil à ce sujet. Vérifiez s'il y a quelque chose que vous n'avez pas vu. Posez-leur des questions au lieu d'exiger des changements. Lorsque vous leur demandez pourquoi ils ont fait X au lieu de Y, ils peuvent avoir une idée que vous n'avez pas. Si vous suggérez un changement, faites-le poliment. Au lieu de

utilisez const au lieu de var

Vous pourriez dire quelque chose comme:

Je vois que CountryCode n'a pas été modifié, est-ce prévu? Serait-il préférable en tant que const d'éviter les modifications involontaires?

Cela vous aidera à mieux comprendre les décisions prises dans le code et à exprimer vos préoccupations en termes faciles à comprendre. Si vous dites simplement de changer les choses sans l'expliquer, cela pourrait être interprété comme du picking. En posant des questions, vous faites un effort pour comprendre leur processus de réflexion et voir comment ils ont résolu le problème qui leur était confié. Lorsque vous suggérez des modifications de cette manière, vous fournissez au développeur les raisons pour lesquelles ces modifications doivent être apportées. Cela permet de mieux comprendre les raisons des modifications demandées.

3. Bonnes idées -

C'est une question importante. Les révisions de code ne doivent pas toujours être négatives. Félicitez le développeur lorsque cela est possible. Si vous voyez quelque chose de bien, faites-le remarquer. Donnez-leur le mérite du bien en plus du mal. J'essaie de souligner quelque chose de bon chaque fois que possible. Cela aide à renforcer l'idée que vous ne recherchez pas seulement le mal. Lorsque vous examinez le code, vous n'essayez pas seulement de transmettre des connaissances au développeur, vous apprenez également d'eux.

N'oubliez pas qu'à la fin, vous essayez tous de faire le même chose, apprenez et écrivez un meilleur code. Vous pouvez apprendre d'eux, ils peuvent apprendre de vous. En fin de compte, tout le monde s'améliore. La meilleure façon d'aider tout le monde est d'expliquer ce que vous pensez et, surtout, faites-le gentiment .

Il est assez troublant qu'une grande partie de ces réponses essaie d'interpréter un problème sérieux de pédagogie comme un problème technique de peluchage.

Si le les soumissionnaires rassemblent du code qui fonctionne à peine, et le soumettre à une révision du code n'est que légèrement mieux pour eux que de lire les messages d'erreur du compilateur.

Vous devriez voir cela comme un rôle de coaching et cela signifie communiquer avec les soumissionnaires collectivement et individuellement. C'est BEAUCOUP PLUS DE TRAVAIL que de simplement trouver les bons commentaires pour votre révision de code. D'une part, vous devrez démontrer encore et encore comment assembler du code qui passera un examen. Cela prendra du temps et de la pratique avec des répétitions.

Si vous n'êtes pas à la hauteur de la tâche, vous devrez pousser pour une formation appropriée pour mettre ces gens au courant.

Félicitations pour votre promotion.

Maintenant que vous êtes promu à un nouveau rôle, il y a de nouvelles responsabilités qui viennent avec ce rôle, et c'est la révision du code.

De votre description, semble-t-il non plus

• L’organisation / l’équipe n’a pas de règles de codage et de règles de bonnes pratiques.
• L’équipe ne tient pas compte de l’existant

Quoi qu'il en soit, cela finira par entraîner un gaspillage d'heures de ressources, car beaucoup d'entre elles doivent être retravaillées.

Ce que je suggèrent plutôt que d'essayer de corriger chaque individu séparément, de convoquer une réunion / discussion / des sessions de partage des connaissances avec l'équipe et de fournir des exemples de pratiques / conventions de codage inappropriées que vous avez rencontrées lors des revues précédentes et comment les améliorer.

Aussi, fournissez-leur les références au guide de codage de l'entreprise (s'il en existe un), ou créez votre propre guide et mettez-le à leur disposition.

Insistez pour que l'examen par les pairs soit effectué avant de lancer la pull request pour que le code soit vérifié par rapport aux règles données.

Par exemple:

J'essayais d'atténuer cela en utilisant tslint mais ils ne l'exécutent pas.

Peut-être qu'ils ne pas l'utiliser parce qu'ils ne savent tout simplement pas comment l'utiliser? Pourquoi ne pas organiser une démonstration pratique et leur montrer à quel point le peluchage peut être utile, et combien de communication et de temps cela peut-il permettre à tout le monde?

Ensuite, une fois que vous leur aurez expliqué le fonctionnement, proposez une règle selon laquelle toutes les demandes d'extraction doivent avoir des résultats d'exécution de charpie associés. De cette façon, vous les responsabilisez et les guidez vers une meilleure productivité.

N'oubliez pas que vous n'avez pas besoin de juger les individus, il vous suffit de juger de la qualité du code et d'attaquer le problème à la racine: le manque de connaissances / compétences.

Quelques points:

• Vos collègues ne devraient pas faire la même erreur plus d'une fois. Dites-leur d'utiliser l'apprentissage par répétition espacée avec Anki. S'ils font la même erreur plus d'une fois, demandez à voir leur carte Anki traiter l'erreur qu'ils viennent de commettre. Au début, leurs cartes Anki ne seront probablement pas assez bonnes, mais ce n'est pas grave, concentrez-vous sur la façon dont ils peuvent améliorer ces cartes. Sur une note latérale, ne leur permettez pas de copier les cartes Anki d'autres personnes.

• Il en va de même pour le code qui ne s'exécute pas ou qui ne peluche pas. Apprenez-leur à peloter leur propre code. Et mieux encore si vous pouvez automatiser ce processus pour eux.

• Interdisez-leur de couper et coller du code. S'ils veulent copier du code à partir d'un endroit, ils doivent le saisir manuellement. S'ils ne le font pas, la mémoire musculaire ne se déclenchera jamais.

• Il y a de fortes chances que vous soyez trop gentil. S'ils commettent du code avant son exécution. Ou s'ils viennent vous voir chaque fois qu'il y a un problème mineur, cela signifie que vous récompensez leur manque d'effort avec une réponse à chaque fois. En d'autres termes, vous les formez pour qu'ils soient tels qu'ils sont. Au lieu de cela, vous devriez leur apprendre à corriger leurs propres erreurs et leur apprendre à rectifier leur propre apprentissage, et non leur donner la réponse chaque fois qu'ils viennent à vous.

• Et enfin , pensez à abandonner ceux qui ne progressent pas avec le temps. Parlez-en à votre direction. Ce n'est pas agréable, mais c'est quelque chose que chaque entreprise doit faire éventuellement, surtout si votre processus de recrutement n'était pas très sélectif au départ.

Mettez-le exactement comme vous nous l'avez fait, car c'était une excellente critique (sauf peut-être pour le bit "utiliser des guillemets simples"; c'est pinailler).

Si les gens qui ne peuvent pas programmer correctement accusent vous de racisme, c'est leur problème. Vous n'êtes pas raciste. Vous faites littéralement votre travail. Ils devraient apprendre à séparer leurs lacunes et leur potentiel pour apprendre à mieux faire leur travail, de la couleur de leur peau.

Soyez factuel et gentil. Voilà.

Fin de l'histoire!

Pour ma part, je pense qu'il est assez complexe, pour ne pas dire impossible, de faire en sorte que des gens qui ne connaissent pratiquement aucune programmation suivent les normes de codage. Je ferais ce qui suit:

1 - soyez toujours amical lors de la révision du code. N'écrivez jamais "vous avez mal agi". Écrivez "Ceci peut être amélioré en faisant X, Y, Z". Lorsqu'ils sont plus expérimentés, vous pouvez même reformuler quelque chose du genre "Que pensez-vous de faire X à la place?"

2 - il se peut qu'ils ne sachent même pas ce qu'est une révision de code et à quoi ça sert. Organisez une réunion pour expliquer ses objectifs

3 - Parlez à votre patron pour essayer de mettre en place des ateliers de programmation, afin que les gens s'améliorent avec le temps

Ensuite, après avoir pris pied et effectivement savoir programmer, j'irais fort avec les normes de codage.

Il y a déjà de très bonnes réponses ici décrivant ce que vous pouvez faire, mais je veux ajouter quelques points au comment, à partir de votre propre expérience (pas en tant que responsable mais en tant que membre de l'équipe).

Premièrement, augmenter la qualité du code à un nouveau standard n'est pas un sprint mais un marathon. La configuration soudaine de 100 règles de linter dans votre CI ne vous mènera pas à votre objectif. Cela rendra les gens fâchés contre vous et / ou ils deviendront très créatifs pour contourner vos règles.

Vous devez faire cuire la grenouille en augmentant progressivement la chaleur ou elle sautera de votre casserole.

Automatiser

Comme d'autres l'ont dit - tout ce qui peut être corrigé automatiquement comme le formatage doit être fait. Faire cela manuellement est une perte de temps. Configurez donc un site wiki et documentez les étapes à suivre pour automatiser cela dans vos IDE sur les scripts de sauvegarde ou de pré-validation (ce avec quoi votre équipe est plus à l'aise). Le fait de documenter cela présente l'avantage que les nouveaux membres de votre équipe sont plus rapides à utiliser cela.

Règles

Ici, cela devient plus délicat. Tout le monde a une perspective et des préférences différentes, même quand ils ne sont pas des débutants. Alors notez les pratiques que vous aimez voir mises en œuvre. Triez-les en groupes doit , devrait et agréable à avoir . Écrivez, pourquoi ces pratiques sont bonnes - quels sont les avantages et ce qui peut arriver si vous ne le faites pas. Je dis écris, car vous serez obligé de réfléchir et de les réévaluer. Il est bon de rafraîchir votre compréhension de ces pratiques et vous pouvez abandonner les règles que vous avez suivies de façon dogmatique jusqu'à présent sans les comprendre (s'il y en a), jusqu'à ce que vous les compreniez vous-même.

Choisissez parmi les groupes obligatoires ceux qui sont les plus faciles à mettre en œuvre et invitez votre équipe à une réunion pour en discuter et les expliquer. Et puis écoutez. Les programmeurs ne sont pas toujours les meilleurs communicateurs, donc ce qui ressemble à "meh, je ne veux pas" en premier, peut avoir un problème sous-jacent qui peut être résolu. Soyez ouvert au compromis. L'avantage doit être en rapport avec le coût nécessaire pour mettre en œuvre chaque règle. Supprimez les règles que vous ne pouvez pas implémenter sans perturber gravement le flux de travail et tuer la productivité. Cela peut être différent entre les langues et leurs écosystèmes.

Cette réunion devrait aboutir à une norme documentée que tout le monde accepte.

Différentes mesures pour l'ancien et le nouveau code

Si vous avez un projet avec 0% de documentation de code et ajoutez ensuite un plugin comme checkstyle, configuré pour casser la construction, vous aurez des centaines d'erreurs. Ceci est frustrant car il est trop difficile de résoudre dans un délai raisonnable, ce qui donne des résultats comme des commentaires de code alá todo . Ce n'est pas ce que vous voulez.

Faites en sorte que le nouveau code soit conforme à la norme sur laquelle vous vous êtes tous mis d'accord.

Chaque ancienne fonction touchée, doit être meilleure qu'avant, si possible. Je dis mieux, car la refactorisation à l'état neuf peut prendre du temps que vous ne recevez pas toujours. Encore une fois, commencez ici avec les fruits à portée de main.

Faites-en un effort d'équipe

Ce qui peut bien fonctionner, c'est la gamification. Si vous obtenez des points pour chaque test que vous écrivez et obtenez la première place sur la liste des scores de l'équipe - cela peut motiver le membre de l'équipe, qui est maintenant à la place 2 pour écrire un nouveau test en réponse (bien sûr, ne vous laissez pas emporter) ).

Si vous voyez un membre de l’équipe qui met bien en œuvre les pratiques, laissez-le également les réviser. La pression des pairs peut motiver à travailler de manière plus disciplinée.

Ne laissez personne travailler seul pendant de longues périodes, si vous avez le pouvoir de décider cela et que vous pouvez l’éviter. Même les personnes les plus disciplinées écriront un meilleur code si quelqu'un d'autre peut donner des commentaires immédiats, poser des questions et dissiper les malentendus.

Ajoutez de nouvelles règles à votre norme

Après un certain temps, rassemblez votre équipe et discutez de la prochaine série de règles. Avoir un plan sur le moment où cela se produit évite les surprises. Si, et combien de nouvelles règles vous ajoutez tous, dépend bien sûr de la façon dont l'équipe gère le dernier ensemble. Lors de cette réunion, vous avez également la possibilité d'ajuster les règles existantes pour mieux représenter la réalité.

Nouveaux membres de l'équipe

En tant que nouveau membre, cela peut être très intimidant être confronté à un énorme ensemble de règles. Ne les jetez pas seuls dans l'eau froide.

Modifier:

Je viens de relire la question et OP a dit que les membres les moins qualifiés viennent toujours à eux même si d'autres membres peuvent revoir aussi. Si cela arrive souvent, il y a une raison. Vos avis sont peut-être meilleurs ou il y a un problème de confiance avec l'autre membre de l'équipe.

Senior I.T. gars ici (20 ans d'expérience), j'ai été à la fois du côté «donner» et «recevoir» des révisions de code, et ce que je peux dire, c'est que le langage, l'approche, les manières et les éloges peuvent être très importants pour la personne examinée.

Imaginez que vous êtes un programmeur junior, avec de bonnes intentions, essayant de coder, d'apprendre et d'être meilleur.

Le réviseur A dit : x est faux, y est faux, z est faux.

Le réviseur B dit : merci pour les progrès que vous avez réalisés sur cette tâche, il y a du très bon travail ici, mais puis-je vous suggérer des améliorations? x peut être amélioré, regardons-le ensemble ... si je fais ce changement, qu'en pensez-vous, êtes-vous d'accord que c'est mieux maintenant? etc etc ...

En d'autres termes, comment vous le cadrez, et si vous donnez un renforcement positif avec l'avis, les choses que vous suggérez peuvent beaucoup plus facilement être interprétées comme des suggestions utiles plutôt que critique émoussée .

Parfois comme IT des gens avec lesquels nous sommes très soucieux du détail et moins préoccupés par les compétences des gens, le ton, la convivialité et les émotions de nos collègues.

Cela ressemble à une approche plus patiente, où vous faites toujours des éloges avec examen, peut vous aider ici. :)

Commencez par organiser une réunion avec l'équipe pour leur enseigner les meilleures pratiques, leur apprendre à coder correctement et leur donner des références pour améliorer leurs compétences (un bon exemple est le livre Clean Code). Une fois qu'ils ont appris à devenir un meilleur programmeur, il est plus légitime pour vous de les revoir.

Un grand nombre des réponses ci-dessus semblent mettre en garde contre les pinaillages, ce qui est compréhensible. De plus, votre écriture semble également vouloir mettre en garde contre les pinaillages.

Notre maison de développement adopte une approche différente. Nous apprécions le pinaillage, mais nous l'abat-jour un peu. Autrement dit, lorsque nous faisons un commentaire sur un nit, nous l'appelons comme tel.

nit: espace supplémentaire

nit: variable non utilisée

Cela inclut des choses que les linters ne trouvent souvent pas, contrairement aux suggestions ci-dessus:

nit: Ces deux lignes pourraient à la place être une, et c'est manière plus lisible.

ou l'inverse,

nit: Cette ligne est assez longue. Ce serait plus lisible de le diviser en deux.

Cela appelle la personne en question: "Hé, c'est une chose mineure, mais c'est un changement que je pense que vous devriez faire . " Notez que cela ne signifie pas que les lentes peuvent être ignorées; ils devraient être corrigés. Cela signifie simplement que vous reconnaissez qu'il s'agit d'un écart mineur qui peut n'avoir qu'une valeur mineure, mais qui est toujours pour l'amélioration de la base de code.

Maintenant, la suggestion d'automatiser l'exécution des linters est toujours une bon car cueillir des lentes n'est peut-être pas une bonne utilisation de votre temps! Mais l'OMI est une réponse incomplète et ne va pas au cœur de la manière de donner des commentaires constructifs et non contradictoires.

En plus des linters et autres éléments mentionnés, j'ajouterais.

Si un nouveau développeur, au lieu de faire des critiques de relations publiques, je ferais de la programmation en binôme (peut-être pendant un mois ou 6 semaines) surtout si le reste de la base de code est en mauvais état ou s'il n'y a pas de normes clairement définies. Je le ferais parce que les gens réagissent très différemment au processus de critique (c'est-à-dire qu'on leur dit qu'ils sont stupides, c'est comment ils l'interprètent) pour leur code et, pour être honnête, cela garantit qu'ils comprennent ce qui leur est dit ( parce que c'est fait en personne). De plus, les linters n'ont qu'une seule bonne réponse, ce qui permet de voir des compromis.

Si le développeur ne veut pas faire cela, il / elle sera hors de l'équipe.

Automation

Le peluchage et les contrôles automatisés sont bénéfiques, mais vous risquez d'être repoussé par l'équipe, car les contrôles les ralentiront jusqu'à ce qu'ils apprennent toutes les règles. Même dans ce cas, je passerais même au niveau supérieur et ferais en sorte que l'IDE utilisé par votre équipe traite tous les avertissements comme des erreurs, de sorte que vos développeurs sont obligés de prêter attention à tout ce que l'EDI remarque.

Plusieurs réviseurs

Demandez à votre équipe de soutenir une politique selon laquelle chaque changement a au moins 2 réviseurs. De cette façon, même si vous finissez par consulter la plupart des critiques, vous savez que quelqu'un d'autre devra également réviser le code. Publiez également les métriques des réviseurs, afin que l'équipe puisse voir qui pèse sur les avis et qui se relâche. Même si quelqu'un est un mauvais codeur, revoir un autre code est une expérience d'enseignement pour lui. Apprenez à vos collègues qu'il est tout aussi important de poser des questions sur une révision de code que de suggérer des améliorations. De cette façon, chaque examen est une opportunité d'apprentissage bidirectionnel, c'est pourquoi tout le monde doit participer.

Appariement

Je suis d'accord avec les réponses qui identifient fondamentalement cela comme une opportunité d'enseignement. Je suis particulièrement d'accord avec la suggestion de jumeler le programme. Il semble que vous ayez essentiellement besoin de former toute votre équipe. Si ce n'est pas votre tasse de thé, il est temps de chercher un nouvel emploi. Sinon, l'appairage est probablement le moyen le plus efficace de les améliorer.

Revues d'équipe

Au lieu de faire des révisions de code par vous-même, vous devriez en faire au moins certaines en équipe. Autrement dit, planifiez une réunion, invitez plusieurs développeurs et demandez à leur de réviser le code, en ajoutant vos commentaires et suggestions jusqu'à ce que tout le monde soit sur la même page. Cela vous permet d'enseigner à plusieurs personnes à la fois. Alternez entre la révision du pire code, qui devrait récupérer beaucoup de commentaires, et votre code, qui devrait soulever beaucoup de questions ("Pourquoi avez-vous procédé ainsi? Que fait cette ligne?").

Livres

Si vous avez un livre préféré contenant les meilleures pratiques pour vos langages de développement, demandez à votre patron d'en acheter quelques exemplaires pour votre équipe et demandez-leur de le lire. Pour C ++, Scott Meyers est une très bonne autorité. Pour Java, vous avez Joshua Bloch, etc.

Groupes d'utilisateurs

Il se peut que vos coéquipiers voient la programmation comme un mal nécessaire, plutôt que comme leur passion première. Vous ne pouvez pas faire grand-chose à ce sujet, à part changer les entreprises. Mais si vous pensez qu'ils sont sur la clôture et qu'ils pourraient être inspirés pour en savoir plus, vous devriez essayer de voir s'il existe des groupes d'utilisateurs pertinents qui se rencontrent dans votre ville et les inviter à vous y rejoindre. Ils n'apprendront pas nécessairement des choses qui sont directement utiles à leur travail quotidien, mais ils devraient au moins voir l'enthousiasme des autres développeurs pour le langage, les bibliothèques et les frameworks. Si vous avez de la chance, une partie de cette excitation déteint sur vos collègues et les motive à améliorer leurs compétences.

Changement de rôle

Il se peut que certains d'entre eux préfèrent vraiment faire autre chose, comme la gestion de programme / projet, ou même la gestion des personnes. Discutez avec chaque membre de l'équipe pour évaluer où il en est, quelles sont ses ambitions, où il se voit dans quelques années, etc. Si l'un d'eux exprime un intérêt pour un rôle différent et que vous pensez qu'il est désespérément loin derrière sur le codage, puis encouragez-les gentiment à explorer ce rôle et faites ce que vous pouvez en formulant des recommandations aux gestionnaires pour y parvenir. Ensuite, dites à votre responsable que vous souhaitez être sur la boucle de recrutement pour tout nouveau codeur de votre équipe et que vous allez relever la barre de manière significative. Vraiment, c'est quelque chose que le gestionnaire devrait faire, mais il peut manquer d'expérience ou de motivation pour le faire. Si cela vous aide à avoir de meilleurs codeurs dans votre équipe, cela vaut la peine de vous salir les mains.

Changement d'équipe

Si votre entreprise compte plusieurs équipes de développement, vous devez soit essayer de rejoindre l'équipe avec les meilleurs développeurs, soit faire de votre équipe cette équipe . Cela signifie essayer de gérer les codeurs les plus faibles sur une équipe inférieure, et débaucher les bons codeurs d'autres équipes. Idéalement, vous devriez travailler au sein de l'équipe la plus percutante (celle qui offre le plus de valeur commerciale à l'entreprise). Si tel est le cas, le braconnage de bons codeurs est en fait bénéfique pour l'entreprise, jusqu'à un certain point. Si vous ne faites pas partie de cette équipe, vous devriez d'abord essayer de faire partie de cette équipe, puis constituer votre équipe d'étoiles.

Vous devriez, bien sûr, recruter votre manager pour cette tâche, car il aura probablement beaucoup plus d'influence et de levier que vous. Vous devez expliquer que votre équipe fournit en réalité moins qu'elle ne le ferait si vous vous débarrassiez des codeurs les plus faibles, car vous passez tellement de temps à réviser / réparer / annuler du code vraiment mauvais. Mais qu'ils pourraient être positifs au sein d'une autre équipe, et ainsi l'entreprise bénéficierait d'un meilleur alignement des développeurs avec les projets commerciaux. C'est-à-dire, un peu de chaises musicales. Bien sûr, vous voulez définir le travail que font les développeurs des autres équipes, afin de savoir lesquelles votre manager devrait essayer de débaucher.

Naturellement, la politique de cette stratégie peut devenir assez compliquée, et cela n'est pas quelque chose que tout le monde est prêt à essayer. Mais à la fin de la journée, votre entreprise est payée pour fournir un produit / service, donc tous ceux qui reçoivent un chèque de paie devraient vouloir la configuration optimale des travailleurs + des projets. Parfois, cela signifie que vous devez former une équipe d'étoiles pour travailler sur les projets les plus importants, et il se peut que vous soyez le mieux placé pour aider à le découvrir.

Gestion

N'oubliez pas que l'équipe d'étoiles a également besoin des meilleurs managers. Donc, si vous vous salissez les mains en essayant de remodeler l'organigramme, assurez-vous de savoir à quel point chacun des gestionnaires est bon. Il semble probable que votre équipe ait des codeurs faibles parce que vos gestionnaires ne sont pas un bon juge des compétences, et il y a peut-être un meilleur gestionnaire dans une autre équipe pour laquelle vous préféreriez travailler. C'est une chose assez importante à prendre en compte, en particulier lorsqu'il s'agit de progresser.

Il semble que vous soyez loin du point où les révisions de code ont un sens. J'ai regardé le code JavaScript, et c'est divin. Lorsque vous écrivez du code, vous le faites fonctionner, puis vous le nettoyez au point où vous pensez que tout va bien, et puis vous le soumettez pour une révision du code.

La personne qui a écrit ceci ne peut pas avoir pensé que ce code est correct. Ou du moins j'espère qu'ils ne l'ont pas fait. Donc, avec un code comme celui-ci, votre réponse ne devrait pas être une révision de code, elle devrait être "faites-le fonctionner, nettoyez-le, et alors vous pouvez obtenir une révision de code".

Je ne pense pas que vous devriez dire à cette personne ce qui ne va pas avec le code. Asseyez-vous avec lui et demandez-lui "comment ce code pourrait-il être amélioré". Et voyez ce qui se passe. S'il semble qu'il ne peut pas voir ce qui ne va pas, alors vous avez peut-être quelqu'un ici qui ne devrait pas être employé dans votre entreprise.

Vous devez commencer par comprendre:

• Quelle est la cause de la situation
• Ce que vous pouvez accomplir (pas ce qui est vraiment bon ou souhaitable; si cela ne peut pas être fait alors cela ne peut pas être fait)
• Vos projets à long terme

La cause de la situation est évidente - l'entreprise employait des personnes sans compétences pour faire leur travail . L'ensemble du processus de recrutement - entretien, tests, etc. - n'a pas fonctionné comme il se doit, ou ce problème n'aurait pas existé en premier lieu.

La deuxième cause - enfin, 99% des les gens travaillent sur la base du bâton et de la carotte. Si l'entreprise n'est pas disposée à appliquer l'un ou l'autre ou les deux selon les besoins, il n'y aura aucune amélioration.

Oui, certaines personnes sont à un niveau supérieur et n'en ont pas besoin, mais la plupart en ont besoin, surtout au niveau débutant.

Donc, vous ne pouvez pas vraiment les amener à s'améliorer.

Alors, que pouvons-nous en conclure? La seule chose que vous pouvez accomplir est de couvrir votre arrière-train.

C'est un objectif valable en soi droite. Je dis simplement, n'espérez pas vraiment plus que cela.

Dans cette optique, avoir un livre de règles clair sur le code vous aidera - en ce sens que vous pouvez le dire à la direction que vous avez clairement affiché les règles et que les règles sont impartiales.

Code linting - eh bien, cela réduira le bruit, ce qui vous fera perdre moins de temps. Un bon conseil. Ne pensez pas qu'ils commenceront à écrire du bon code fonctionnel.

Mais cela ne fonctionne que pour des problèmes très simples.

Comme les problèmes être résolu dans le code croître au-delà du stade débutant, il y aura mille situations que le linter ne reconnaîtra pas ... et qu'un humain reconnaîtra instantanément comme une mauvaise pratique de codage. quelque chose avec multi-threading? Requêtes de base de données complexes? Des trucs client / serveur? Quelque chose au-delà des bases?

Ateliers de programmeurs? Je doute que cela vous aide. S'ils voulaient apprendre, ils auraient déjà appris, ou ils auraient demandé de l'aide. Et c'est quelque chose que l'on apprend depuis des années et des années. Quelques semaines d'un atelier de programmeur ne transformeront personne en programmeur, pas plus de quelques semaines d'un cours intensif de boxe transformeront un Joe Shmoe moyen en boxeur professionnel.

Référentiel strictement verrouillé où personne ne peut pousser un commit jusqu'à ce qu'il réussisse à la fois l'examen et les tests unitaires - cela vous aidera à la fois vous et le projet à long terme. Cela fera également hurler les mauvais auteurs de code.

Le reste appartient à l'entreprise. Oui, il peut et doit organiser une sorte d'apprentissage et d'aide, car il les a employés en premier lieu. Mais ce sera inutile à moins qu'il y ait des conséquences pour ne pas apprendre.