Comment «neutraliser» ceux qui écrivent du mauvais code dans l'équipe?

J'ai toujours aimé cet article sur JoelOnSoftware intitulé "Faire avancer les choses quand vous n'êtes qu'un grognement". Je pouvais surtout raconter quand j'étais débutant (et avoir toujours l'impression que j'en serai TOUJOURS un).

Environ # 4, neutralisant les bozo. Quels conseils avez-vous pour réellement mettre en œuvre cela dans des situations réelles au travail? Cela ne semble pas être aussi facile (au moins dans notre équipe) que de simplement enregistrer un bogue contre le mauvais code de quelqu'un. Qu'est-ce qui fonctionne pour vous tous là-bas?

team bug

— C Johnson
source

Des fusils. Beaucoup d'entre eux.

— CodesInChaos

Réponses:

Évaluation permanente.

À la fin de chaque journée, passez 30 minutes pour revoir ce qu'ils ont écrit. S'ils ont fait quelque chose de mal, faites-les réécrire.

À moins que vous ne le fassiez, un jour, vous vous rendrez compte qu'une partie de votre application, tout en étant apparemment capable de faire le travail, est totalement irréalisable, mal conçue et causera de nombreux problèmes à l'avenir - ou même demain.

Même si cela les rendra moins productifs, ce sera encore mieux s'ils produisaient du bon code contre deux fois plus de taille mais un gonflement incontrôlable de bogues.

— P Shved
source

Très bonne réponse. Si je peux simplement ajouter à cela, si cette personne est un pair, il est préférable que le chef d'équipe le fasse. De cette façon, la réponse à la question de ne pas recommencer serait beaucoup plus efficace si elle était commandée par la hiérarchie de la boutique.

@Surfer, c'est exactement le contraire. On devient chef d'équipe en faisant des choses comme ça, en proposant de meilleures solutions, en se souciant de ce que fait l'équipe. Non l'inverse. (Mais, bien sûr, obtenir de l'aide de niveaux hiérarchiques supérieurs aide).

— P Shved

Alors la question devient, qui a le pouvoir de les faire réécrire? Je suppose que la réponse est, l'autorité morale de toute l'équipe, si les problèmes sont diffusés à toute l'équipe.

— C Johnson

En l'absence d'un mécanisme d'examen du code robuste pour chaque membre de l'équipe, cela est approprié. Il convient également de s'assurer que le bozo ne creuse pas un trou vraiment profond (même ne vaut pas le coût de la fixation) avant de lui demander de le retravailler.

— mattnz

Si la personne ne sait tout simplement pas mieux, mais veut apprendre, fournissez un mentorat et une révision du code. Assurez-vous qu'ils sont exposés à un bon code.

Les développeurs vraiment pauvres sont ceux qui sont mal placés et se battent pour apprendre quelque chose de nouveau. Votre seul espoir est de les laisser souffrir en maintenant leur propre gâchis ou certaines des choses les plus simples. Idéalement, une personne en position d'autorité se lève et dit se conformer ou partir.

— JeffO
source

L'attitude compte vraiment. Je trouve généralement les débutants plus humbles et ouverts aux critiques de code et aux critiques. Il est facile de parler à ces gens. Et vous pouvez facilement leur parler de leurs faiblesses. Ce sont les vétérans arrogants, qui se briseront comme un million de morceaux de verre lorsqu'ils sont critiqués pour leur travail.

— C Johnson