Que faites-vous avec un développeur qui ne teste pas son code? [fermé]

https://stackoverflow.com/questions/139228

02-07-2019
|

Question

L'un de nos développeurs écrit continuellement du code et l'insère dans le contrôle de version sans le tester. La qualité de notre code en souffre.

En plus de se débarrasser du développeur, comment puis-je résoudre ce problème?

EDIT

Je lui ai parlé de ce nombre de fois et je lui ai même donné un avertissement écrit

La solution

Si vous effectuez systématiquement des analyses de code avant d'autoriser un développeur à valider le code, votre problème est en grande partie résolu. Mais cela ne semble pas être votre cas, c'est donc ce que je recommande:

Parlez au développeur. Discutez des conséquences pour les autres membres de l'équipe. La plupart des développeurs veulent être reconnus par leurs pairs, cela pourrait donc suffire. Indiquez également qu'il est beaucoup plus facile de corriger les bogues dans votre code que le code vieux de plusieurs semaines. Cette partie a du sens si vous avez une sorte de propriétaire de code en place.
Si cela ne fonctionne pas après un certain temps, essayez de mettre en place une politique qui rendrait désagréable la validation d'un code buggy pour l'auteur. Un moyen populaire est de rendre la personne qui a cassé la construction responsable des tâches ménagères de la création de la suivante. Si votre processus de génération est entièrement automatisé, recherchez une autre tâche élémentaire à prendre en charge. Cette approche présente l’avantage supplémentaire de ne cibler personne en particulier, ce qui la rend plus acceptable pour tout le monde.
Utilisez des mesures disciplinaires . Selon la taille de votre équipe et de votre entreprise, celles-ci peuvent prendre de nombreuses formes.
Démarrez le développeur. Il existe un coût associé à la conservation des pommes pourries. Quand vous en arrivez là, le développeur se fiche de ses collègues développeurs et vous avez déjà un problème de personnel. Si l'environnement de travail devient empoisonné, vous risquez de perdre beaucoup plus - en termes de productivité et de ressources humaines - que ce seul et même mauvais développeur.

Autres conseils

Si vous pouvez effectuer des revues de code, c’est l’endroit idéal pour l’attraper.

Nous avons besoin de commentaires avant de fusionner avec le tronc d'itération, de sorte que tout est capturé ensuite.

Battements rituels! Pour chaque bug, un coup de fouet!

(Une blague pour ceux qui ne l’ont pas compris)

En tant que développeur qui teste rarement son propre code, je peux vous dire la seule chose qui m'a fait changer lentement de comportement ...

Visibilité

Si l'environnement permet d'extraire du code, d'attendre que les utilisateurs trouvent des problèmes, puis de demander essentiellement "Et si on faisait maintenant?" Après avoir modifié le code, il n’ya plus vraiment intérêt à tester vos propres données.

Les revues de code et la collaboration vous encouragent à travailler à la fabrication d'un produit de qualité bien plus que si vous livriez simplement le "Widget X" pendant que vos collègues travaillent sur "Widget Y" et "Widget Z"

Plus votre travail est visible, plus vous avez de chances de vous soucier de son efficacité.

Révision du code. Collez tous vos développeurs dans une salle tous les lundis matins et demandez-leur de leur apporter leur plus belle réalisation basée sur le code de la semaine précédente lors de la réunion.

Laissez-les prendre le feu des projecteurs et expliquez-leur ce qu’ils ont fait. Demandez-leur d'apporter des copies du code afin que les autres développeurs puissent voir de quoi ils parlent.

Nous avons démarré ce processus il y a quelques mois et il est étonnant de constater l'ampleur des contrôles de qualité sub-conscients. Après tout, si les développeurs sont simplement invités à parler de ce qui les passionne le plus, ils seront ravis de montrer leur code aux gens. Ensuite, les autres développeurs verront les erreurs de qualité et discuteront publiquement pourquoi ils se trompent et comment le code devrait être écrit à la place.

Si cela ne permet pas à votre développeur d'écrire du code de qualité, il ne convient probablement pas pour votre équipe.

Faites-en une partie de ses objectifs de la revue annuelle. S'il ne l'obtient pas, pas d'augmentation de salaire.

Parfois, même si vous devez accepter le fait que quelqu'un ne convient pas à votre équipe / à votre environnement, cela devrait être un dernier recours et peut être difficile à gérer, mais si vous avez épuisé toutes les autres options, cela peut être la meilleure chose à faire. à long terme.

Dites au développeur que vous souhaitez modifier ses pratiques dans les 2 semaines ou vous allez commencer la procédure disciplinaire de votre entreprise. Offrez autant d'aide et d'assistance que possible, mais si vous ne pouvez pas changer cette personne, elle ne convient pas à votre entreprise.

À l’aide du régulateur de vitesse ou d’un outil similaire, vous pouvez faire en sorte que les vérifications déclenchent automatiquement une construction et des tests unitaires. Vous devez toujours vous assurer qu'il existe des tests unitaires pour toute nouvelle fonctionnalité qu'il ajoute, ce que vous pouvez faire en consultant ses archives. Cependant, il s’agit d’un problème humain et une solution technique ne peut aller jusqu’à présent.

Pourquoi ne pas simplement lui parler? Il ne vous fera probablement pas réellement mordre.

Faites-lui "garder" " la construction et devenir le responsable de la construction. Cela lui donnera moins de temps pour développer du code (augmentant ainsi les performances de chacun) et lui apprenant pourquoi une bonne construction est si nécessaire.
Appliquer les cas de test - le code ne peut pas être soumis sans les cas de test unitaires. Modifiez le système de génération de sorte que, si les scénarios de test ne sont pas compilés et exécutés correctement, ou n’existent pas, l’archivage complet de la tâche soit refusé.

-Adam

Publiez des statistiques sur la couverture du code de test par développeur, ce serait après lui avoir parlé.

Voici quelques idées tirées d'un cabanon marin.

Intro
   What shall we do with a drunken sailor, (3×)
   Early in the morning?
Chorus
   Wey–hey and up she rises, (3×)
   Early in the morning!
Verses
   Stick him in a bag and beat him senseless, (3×)
   Early in the morning!
   Put him in the longboat till he’s sober, (3×)
   Early in the morning!

etc. Remplacer "marin ivre" avec un "développeur bâclé".

En fonction du type de système de contrôle de version que vous utilisez, vous pouvez configurer des règles d’archivage qui forcent le code à satisfaire certaines exigences avant d’être autorisé à effectuer l’archivage. Si vous utilisez un système tel que Team Foundation Server, vous avez la possibilité de spécifier les exigences en matière de couverture de code et de tests unitaires pour les enregistrements.

Vous savez, c’est une excellente occasion d’éviter de le choisir (bien que je convienne avec vous de parler avec lui) et de mettre en place un processus de test d’abord en interne. Si les règles ne sont pas claires et que les attentes sont connues de tous, j'ai constaté que ce que vous décrivez n'est pas si rare. Je trouve que le schéma de développement test-first fonctionne bien pour moi et améliore la qualité du code.

Ils peuvent être trop axés sur la vitesse plutôt que sur la qualité.

Cela peut amener certaines personnes à se dépêcher de résoudre certains problèmes pour effacer leur liste et voir ce qui se produit plus tard dans les rapports de bugs.

Pour rectifier cet équilibre:

n'affectez que quelques éléments à la fois dans votre système de suivi des problèmes,
révisez le code et testez tout ce qu'ils ont " terminé " dès que possible afin qu'il soit de retour avec eux immédiatement s'il y a des problèmes
parlez-leur de vos attentes concernant le temps nécessaire à un élément pour le faire correctement

La programmation par les pairs est une autre possibilité. S'il est avec un autre développeur qualifié de l'équipe qui meurt, répond aux normes de qualité et connaît la procédure, cela présente quelques avantages:

Avec un développeur expérimenté sur l'épaule, il saura ce qu'on attend de lui et verra la différence entre son code et un code à la hauteur de ses attentes
L'autre développeur peut appliquer une première stratégie de test: ne pas autoriser l'écriture de code tant que les tests ne sont pas écrits pour elle
De même, l'autre développeur peut vérifier que le code est conforme aux normes avant son enregistrement, ce qui réduit le nombre de mauvais enregistrements

Tout cela exige bien sûr de la part de la société et des développeurs d'être réceptifs à ce processus, ce qu'ils ne sont peut-être pas.

Il semble que les gens proposent de nombreuses solutions imaginatives et sournoises à ce problème. Mais le fait est que ce n'est pas un jeu. Concevoir des systèmes élaborés de pression des pairs pour "nommer et honte" lui ne va pas aller à la racine du problème, à savoir. pourquoi n'écrit-il pas des tests?

Je pense que vous devriez être direct. Je sais que vous dites que vous lui avez parlé, mais avez-vous essayé de savoir pourquoi il n’écrit pas de tests? À ce stade, il sait manifestement qu'il devrait le exister, donc il doit sûrement y avoir une raison pour laquelle il ne fait pas ce qu'on lui a demandé de faire. Est-ce la paresse? Procrastination? Les programmeurs sont célèbres pour leur ego et leurs opinions bien arrêtées. Peut-être est-il convaincu, pour une raison quelconque, que les tests sont une perte de temps ou que son code est toujours parfait et ne nécessite pas de tests. S'il est un programmeur immature, il pourrait ne pas comprendre pleinement les implications de ses actions. S'il est "trop ??mature" il est peut-être trop déterminé. Quelle que soit la raison, abordez-le.

Si cela revient à une question d’opinion, vous devez lui faire comprendre qu’il a besoin de mettre de côté son opinion personnelle et de ne suivre que les règles. Indiquez clairement que s’il ne peut pas avoir la confiance de suivre les règles, il sera remplacé. S'il ne le fait toujours pas, faites-le.

Une dernière chose - documentez toutes vos discussions avec tous les problèmes résultant de ses modifications. Au pire, vous serez peut-être obligé de justifier vos décisions. Dans ce cas, la preuve documentaire sera sûrement d'une valeur inestimable.

Collez-le sur sa propre branche de développement et n’apportez ses affaires dans le coffre que lorsque vous savez qu’elles ont fait l’objet de tests approfondis. Cela pourrait être un endroit où un outil de gestion de contrôle de source distribué tel que GIT ou Mercurial pourrait exceller. Bien qu'avec la prise en charge accrue des branches / fusions dans SVN, vous n’ayez pas trop de mal à la gérer.

EDIT

C’est seulement si vous ne pouvez pas vous débarrasser de lui ou le convaincre de changer de comportement. Si vous n'arrivez simplement pas à arrêter ce comportement (en changeant ou en tirant), le mieux que vous puissiez faire est de protéger le reste de l'équipe des mauvais effets de son codage.

Si vous vous trouvez à un endroit où vous pouvez affecter les stratégies, apportez des modifications. Révisez les codes avant les enregistrements et intégrez les tests dans le cycle de développement.

Cela semble assez simple. Faites-en une exigence et s'il ne peut pas le faire, remplacez-le. Pourquoi voudriez-vous le garder?

D'habitude, je ne préconise pas cela à moins que tout le reste échoue ...

Parfois, un tableau du nombre de bogues par développeur affiché publiquement peut appliquer suffisamment de pression des pairs pour obtenir des résultats favorables.

Essayez la carotte, faites-en un jeu amusant.
E.g Le plugin de jeu d'intégration continue pour Hudson
http://wiki.hudson-ci.org/ display / HUDSON / Le plugin + Continuous + Integration + Game +

Placez vos développeurs dans des branches de votre code, selon une logique telle que, par fonctionnalité, par correction de bogue, par équipe de développement, peu importe. Ensuite, les mauvais enregistrements sont isolés dans ces branches. Lorsque vient le temps de créer, de fusionner avec une branche de test, de rechercher des problèmes, de résoudre un problème, puis de fusionner votre version dans une branche principale.

Ou supprimez les droits de validation de ce développeur et demandez-leur d'envoyer leur code à un développeur plus jeune pour qu'il le vérifie et le teste avant de le valider. Cela pourrait motiver un changement de procédure.

Vous pouvez créer un rapport contenant des erreurs dans le code avec le nom du programmeur responsable de ce logiciel.

S'il s'agit d'une personne raisonnable, discutez du rapport avec elle.

S'il se soucie de sa "réputation" publie le rapport régulièrement et le met à la disposition de tous ses pairs.

S'il n'écoute que "l'autorité", rédigez le rapport et transmettez le problème à son responsable.

Quoi qu’il en soit, j’ai souvent vu que, lorsque les gens sont conscients de leur apparence extérieure, ils changent de comportement.

Hé, cela me rappelle quelque chose que j'ai lu sur xkcd :)

Faites-vous référence à l'écriture de tests unitaires automatisés ou de tests unitaires manuels avant l'enregistrement?

Si votre boutique n'écrit pas de tests automatisés, alors son enregistrement de code qui ne fonctionne pas est téméraire. Est-ce que cela a un impact sur l'équipe? Avez-vous un département QA formalisé?

Si vous créez tous des tests unitaires automatisés, je suggérerais qu'une partie de votre processus de révision de code inclue également les tests unitaires. Il deviendra évident que le code n'est pas acceptable selon vos normes lors de votre examen.

Votre question est plutôt large, mais j'espère avoir fourni une orientation.

Je conviens avec Phil que la première étape consiste à lui parler individuellement et à lui expliquer l’importance de la qualité. Une mauvaise qualité peut souvent être liée à la culture de l'équipe, du service et de l'entreprise.

Faites des cas de test exécutés l’un des éléments livrables avant qu’un élément soit considéré "terminé".

Si vous n'avez pas exécuté de scénario de test, le travail n'est pas terminé et si le délai est dépassé avant l'exécution documentée du scénario de test, il n'a pas livré à temps et les conséquences seraient les mêmes. s'il n'avait pas terminé le développement.

Si la culture de votre entreprise ne le permet pas, et si elle privilégie la rapidité à la précision, le problème est probablement à l'origine du problème et le développeur réagit simplement aux mesures incitatives existantes - il est récompensé pour son travail. beaucoup de choses à moitié assed plutôt que moins de choses correctement.

Faites en sorte que la personne nettoie les latrines. A travaillé dans l'armée. Et si vous travaillez en groupe avec des personnes qui mangent beaucoup de plats indiens, il ne leur faudra pas longtemps pour qu’elles se mettent à faire la queue.

Mais ce n'est que moi ...

Chaque fois qu'un développeur vérifie quelque chose qui ne compile pas, mettez de l'argent dans un pot. Vous réfléchirez à deux fois avant de vous enregistrer.

Malheureusement, si vous lui avez déjà parlé plusieurs fois et que vous lui avez donné des avertissements écrits, je dirais qu'il est temps de l'éliminer de l'équipe.

Vous pouvez trouver des réponses utiles ici: Comment faire en sorte que les programmeurs débutants écrivent des tests ?

Licencié sous: CC-BY-SA avec attribution

Non affilié à StackOverflow