Comment désarme-t-on un codeur cow-boy? [fermé]

J'ai trouvé une question (code cow-boy sur l'équipe), mais c'était plus lié à "Ninja Coder" qu'au problème que j'ai.

J'ai un membre de l'équipe qui est un exemple vivant de " Cowboy Coder ". Je comprends qu'on ne puisse pas changer les gens, mais est-ce un moyen de le faire cesser de se comporter comme un "Cowboy Coder"?

Il refuse d'écouter l'équipe et il a récemment arrêté les revues de code, les tests unitaires, le partage des détails de mise en œuvre, etc.

Oui, il "code" rapidement, mais son code est juste un générateur de bugs. Les autres membres de l'équipe et moi sommes dans une "phase de correction de bugs" et 80% des bugs proviennent de son code. Je ne veux pas réparer ses insectes. Et la direction est aveugle, ou ne veut pas voir cela, ou peut-être qu’elle aime sa "rapidité".

Existe-t-il un moyen pour moi (en tant que son plus jeune collègue, pas son patron) de pouvoir faire quelque chose à ce sujet?

Comment puis-je désarmer ce codeur cow-boy?

J'ai l'impression d'être la dernière personne qui se soucie vraiment du projet.

Je vois quelques options:

• Abordez le codeur avec vos préoccupations. Cela doit être fait comme une critique constructive avec des points spécifiques. Avant de prendre des mesures plus importantes, il convient de soulever les problèmes directement et en privé afin de donner à la personne l'occasion de changer.
• Recueillez des informations et des statistiques et apportez-les à la direction. La direction peut sembler ne pas s'en soucier, mais il est souvent important de faire l'effort quand même au cas où cela fonctionnerait. Les conséquences négatives possibles incluent l'aliénation d'autres personnes qui n'apprécient pas les plaintes adressées à la direction.
• Trouvez un pair du codeur cow-boy et discutez-en en privé. Il / elle pourrait avoir une meilleure chance de faire écouter la personne.
• Demandez à travailler sur une autre équipe. Ne résoudra pas le problème mais vous garderez votre santé mentale. À tout le moins, travaillez toujours au mieux de vos capacités et ne vous laissez pas décourager.
• Quittez l'organisation si personne n'écoute. Cela ressemble à un mauvais environnement.

Il refuse d'écouter l'équipe, et il a récemment arrêté les critiques de code, les tests unitaires, le partage des détails de mise en œuvre ...

Les révisions de code ne nécessitent pas nécessairement que le codeur soumette le travail pour révision.

Un moyen facile de suivre ce qu'il fait est de surveiller l'historique de VCS et de rechercher ses enregistrements. Si son code vous inquiète, c'est un moyen facile de le trouver. Obtenez un historique des diff, regardez ce qu'il a écrit et voyez si des drapeaux rouges vous sautent aux yeux. Catch ses checkins assez rapidement et si vous trouvez un problème, vous pouvez annuler la validation et l'envoyer par courrier électronique à cet effet. Vous êtes autorisé à appeler les membres de votre équipe, même en tant que codeur débutant, lorsque vous constatez que quelque chose ne va manifestement pas.

Oui, il "code" rapidement, mais son code est juste un générateur de bugs. Les autres membres de l'équipe et moi sommes dans une "phase de correction de bugs" et 80% des bugs proviennent de son code. Je ne veux pas réparer ses insectes. Et la direction est aveugle, ou ne veut pas voir cela, ou peut-être qu’elle aime sa "rapidité".

Le code provient d'exigences. Les exigences résultent en des tests exécutables qui vérifient que les exigences ont été satisfaites. Ces tests peuvent être davantage décomposés et peuvent être écrits avant que des modifications ne soient apportées afin de vérifier que les modifications répondent aux exigences (rouge-vert-refactor; l’essence de la TDD).

Ajoutez une métrique "couverture de code" au serveur de build de votre équipe (espérons que vous en ayez une; sinon, c'est votre premier problème). Le simple fait de vérifier que les tests unitaires sont satisfaisants ne résoudra pas les problèmes liés à son nouveau code non-TDDed, créé dans des zones dépourvues de tests unitaires. Après avoir exécuté tous les tests unitaires, le serveur de build devrait idéalement avoir exécuté chaque ligne de code, mais il y a certaines choses pour lesquelles vous ne pouvez pas tester les tests unitaires. De manière réaliste, vous devriez toujours pouvoir vous attendre à une couverture de 95% ou plus (ou à exclure certaines bibliothèques ou certains types de fichiers de la couverture). Tôt ou tard, votre cow-boy enregistrera quelque chose qui brisera la construction parce qu'il aura baissé le niveau de couverture au-dessous du seuil et que vous l'appellerez.

Et en ce qui concerne la "vitesse", la vitesse est la rapidité avec laquelle vous faites "faire" les choses, et ce n'est "fait" que si c'est fait correctement. Vous pouvez le dire à vos gestionnaires de cette façon. Considérez un mécanicien automobile qui, lorsque le responsable emmène sa BMW pour changer d’huile, oublie de débrancher le bouchon du carter d’huile et que toute la nouvelle huile s’écoule avant même qu’il ne quitte le garage. Bien sûr, la vidange n'a pris que cinq minutes, mais le responsable ne s'en soucie pas lorsque le moteur de sa voiture se grippera en rentrant chez lui. Il va se soucier que le mécanicien ait raté une étape, cela va lui coûter beaucoup de temps et d'argent supplémentaire à réparer. En ce moment, il paye un cow-boy pour faire le travail très vite, et ensuite il ' s payer au reste de l’équipe une somme beaucoup plus importante pour venir et refaire le travail correctement. Quel est vraiment l'avantage de continuer à laisser le cow-boy faire son truc?

Existe-t-il un moyen pour moi (en tant que son plus jeune collègue, pas son patron) de pouvoir faire quelque chose à ce sujet?

Appelez-le. Lorsque vous trouvez quelque chose qu'il a foiré, montrez-lui comment son code échoue, comment il aurait pu le prévenir au préalable (y compris la conception appropriée, le TDD, les révisions de code) et ce que vous deviez faire ou aurait dû faire à la suite pour réparer son code cassé.

J'ai l'impression d'être la dernière personne qui se soucie vraiment du projet.

klaxons hurlants, lumières clignotantes, sirènes gémissantes - si vous avez vraiment le sentiment d'être la seule personne qui se soucie de la qualité du code produit par l'équipe, alors il y a un grave problème. Si vous sentez que vous essayez d'entraîner toute l'équipe à frapper et crier dans l'ère du bon codage, et que c'est trop lourd à transporter, alors laissez tomber. S'il y a une autre équipe dans l'entreprise qui fait bien les choses, demandez un transfert, sinon, sortez de l'enfer.

Accédez à la gestion avec vos statistiques sur le nombre de bogues / problèmes provenant de ce développeur. Expliquez-leur que la correction de leurs bugs affecte la productivité de votre équipe. Si en effet 80% des problèmes proviennent d'une seule personne, il faut régler ce problème. Tant que vous expliquez à la direction les termes avec lesquels elle peut être d'accord ("le temps perdu, c'est de l'argent gaspillé"), ils interviennent.

En outre, ce développeur devrait corriger ses propres bogues / problèmes, il peut donc être utile de leur attribuer ces problèmes. Votre équipe ne devrait pas couvrir cette personne.

Existe-t-il un moyen pour moi (en tant que son plus jeune collègue, pas son patron) de pouvoir faire quelque chose à ce sujet?

La pression des pairs et prêcher par l'exemple sont les seuls moyens efficaces. Les meilleurs moyens sont faits par leur chef / chef. Si vous n'êtes pas leur patron / responsable, parlez-en à ceux qui le sont. Mais à la fin, c'est à eux de s'en occuper, pas à vous. Assurez-vous que vous faites du bon travail et que les choses ont tendance à s'arranger.

Il refuse d'écouter l'équipe, et il a récemment arrêté les critiques de code, les tests unitaires, le partage des détails de mise en œuvre ...

N'avez-vous pas de chemin documenté pour le code lors de la révision, du test et de la mise en œuvre? Sinon, vous avez un problème plus vaste. Si vous le faites, c'est quelque chose qui doit être intensifié.