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.