Comment désarquez-vous un codeur de cow-boy?
J'ai trouvé une question (code cowboy de l'équipe), mais c'était plus lié au "Ninja Coder" puis du problème que j'ai.
J'ai un membre de l'équipe qui est un exemple de vie pur de "codboy coder". Je comprends que l'on ne peut pas changer les gens, mais c'est un moyen de le faire arrêter de se comporter comme un "codboy coder"?
Il refuse d'écouter l'équipe et il a récemment arrêté des critiques de code, des tests unitaires, partageant les détails de la mise en œuvre, etc.
Oui, il "codes" 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 fixation de bugs" et 80% des bogues provient de son code. Je ne veux pas réparer ses insectes. Et la direction est aveugle ou ne veut pas voir cela, ni peut-être qu'ils aiment sa "vitesse".
Y a-t-il un moyen que je (comme son collègue plus jeune par âge, pas son patron) puisse faire quelque chose à ce sujet?
Comment puis-je désarmer ce codeur de cow-boy?
Je me sens comme si je suis le dernier qui se soucie vraiment du projet.
Je vois quelques options:
- Approchez le codeur avec vos préoccupations. Cela doit être fait comme critique constructive avec des points spécifiques. Avant de prendre des mesures plus importantes, il convient de susciter des préoccupations directement et de manière privée pour donner à la personne la possibilité de changer.
- Recueillir des informations et des statistiques et l'amener à la gestion. La direction peut ne pas sembler se soucier, mais il est souvent important de faire l'effort de toute façon au cas où cela fonctionnerait. Les conséquences négatives possibles incluent l'aliénation des autres qui n'apprécient pas les plaintes à la gestion.
- Trouvez un pair du codeur de cow-boy et discutez-le en privé. Il/elle aurait peut-être une meilleure chance d'avoir la personne à écouter.
- 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 votre capacité et ne le laissez pas vous faire glisser.
- Quitter l'organisation si personne n'écoutera. Cela ressemble à un mauvais environnement.
Il refuse d'écouter l'équipe et il a récemment arrêté des critiques de code, des tests unitaires, partageant les détails de la mise en œuvre ...
Les critiques de code ne nécessitent pas nécessairement que le codeur soumet le travail de révision.
Un moyen facile de garder une trace de ce qu'il fait est de garder un œil sur l'histoire de la VCS, à la recherche de ses check-ins. Si vous êtes inquiet de son code, c'est un moyen facile de le trouver. Obtenez une histoire de diff, regardez ce qu'il a mis, et voyez si des drapeaux rouges sautent à vous. Attraper suffisamment de Checkins assez rapidement et si vous trouvez un problème, vous pouvez le faire rebondir et l'envoyer par courrier électronique à cet effet. Vous êtes autorisé à appeler vos collègues membres de l'équipe, même comme un codeur junior, lorsque vous voyez quelque chose de manifestement faux.
Oui, il "codes" 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 fixation de bugs" et 80% des bogues provient de son code. Je ne veux pas réparer ses insectes. Et la direction est aveugle ou ne veut pas voir cela, ni peut-être qu'ils aiment sa "vitesse".
Le code provient des exigences. Les exigences entraînent des tests annulables qui vérifient les exigences ont été remplis. Ces tests peuvent être encore décomposés et peuvent être écrits avant que les modifications soient apportées pour vérifier que les modifications répondent aux exigences (refacteur rouge-vert; l'essence de TDD).
Ajoutez une "couverture de code" métrique sur le serveur de construction de votre équipe (j'espère que vous en avez un; sinon, c'est votre premier problème). Vérification simplement que les tests d'unités passent ne pas attraper les problèmes de son nouveau code non-TDDED, fabriqués dans des zones qui n'ont pas de tests d'unités. Après avoir exécuté tous les tests de l'unité, le serveur de construction doit idéalement avoir exécuté toutes les lignes de code, mais il y a vraiment des choses que vous ne pouvez pas utiliser l'unité. De manière réaliste, vous devriez toujours pouvoir vous attendre à une couverture de 95% ou mieux (ou exclure certaines bibliothèques ou types de fichiers de la couverture). Tôt ou tard, votre cow-boy va vérifier quelque chose qui enfreint la construction car il a laissé tomber le niveau de couverture en dessous du seuil et vous l'appelez.
Et jusqu'à la "vitesse" est concerné, la vitesse est la rapidité avec laquelle vous obtenez des choses "faites", et ce n'est pas "fait" jusqu'à ce que cela soit fait correctement. Vous pouvez la mettre à vos gestionnaires de cette façon; Considérez un mécanicien automobile qui, lorsque le gestionnaire prend son BMW pour obtenir un changement de pétrole, oublie de sortir de la branche d'huile. En conséquence, toute la nouvelle huile se déverse avant même de sortir du garage. Bien sûr, le changement d'huile n'a pris que cinq minutes, mais le responsable ne se soucie pas de cela lorsque le moteur de son voiture s'empare du chemin du retour. Il veillera à ce que le mécanicien a manqué une étape, cela va lui coûter beaucoup de temps et d'argent supplémentaires pour avoir fixé. À l'heure actuelle, il paie un cow-boy de faire le travail vraiment rapide, puis il paie le reste de l'équipe une somme beaucoup plus importante à entrer et à relancer le travail correctement. Quoi, vraiment, c'est l'avantage de continuer à laisser le cow-boy faire sa chose?
Y a-t-il un moyen que je (comme son collègue plus jeune par âge, pas son patron) puisse faire quelque chose à ce sujet?
Appelez-le. Lorsque vous trouvez quelque chose qu'il fous, montrez-lui comment son code échoue, comment il aurait pu empêcher le problème en premier lieu (y compris la conception appropriée, la TDD, les critiques de code) et ce que vous étiez ou si vous étiez obligé de faire en conséquence pour réparer son code brisé.
Je me sens comme si je suis le dernier qui se soucie vraiment du projet.
Klaxons blâmer, lumières clignotants, siirens gémissant - Si vous vous sentez vraiment comme si vous êtes la seule personne qui se soucie de la qualité du code produit par l'équipe, alors il y a un problème grave. Si vous sentez que vous essayez de traîner toute l'équipe de donner des coups de pied et de crier à l'ère du bon codage, et c'est trop de poids pour transporter, puis laissez-le tomber. S'il y a une autre équipe de la société qui le fait correctement, demandez un transfert, sinon obtenez l'enfer.
Allez à la gestion avec vos statistiques sur le nombre de bugs/problèmes provenant de ce développeur. Expliquez-leur que la fixation de leurs bugs affecte la productivité de votre équipe. Si, en effet, 80% des problèmes proviennent d'une personne, cela doit certainement être adressé. Tant que vous l'expliquez à la direction en termes, ils peuvent être d'accord avec (c'est-à-dire que le temps perdu est de l'argent gaspillé "), ils interviendront.
En outre, ce développeur devrait corriger ses propres bugs/problèmes, il peut donc être utile de leur attribuer ces problèmes. Votre équipe ne devrait pas couvrir cette seule personne.
Il refuse d'écouter l'équipe et il a récemment arrêté des critiques de code, des tests unitaires, partageant les détails de la mise en œuvre ...
Vous n'avez pas de chemin d'accès documenté pour le code grâce à la révision, au test et à la mise en œuvre? Sinon, vous avez un problème plus large. Si vous le faites, c'est quelque chose qui doit être escaladé.