Comment faire face à quelqu'un qui n'aime pas l'idée des revues de code?

De toute évidence, si la direction consacre du temps à passer en revue les codes, tout le monde doit le faire.

Mais il y a toujours ces gars (ou filles) qui résistent avec chaque once de leur être.

Comment gérez-vous efficacement le traitement de ce scénario lorsque vous le traitez en tant que pair examinateur?

Il résiste à cause de la peur . Ce conditionnement peut être le résultat d'une ou de plusieurs mauvaises expériences antérieures concernant la révision, en tant qu'enfant, à l'école, au travail ou même dans votre équipe actuelle. Dans nos sociétés modernes, il est très courant pour nous de confondre le travail de quelqu'un avec sa valeur en tant qu'être humain. C'est pourquoi les critiques au travail ne sont pas bien perçues. C'est aussi pourquoi parler en public dans l'une des phobies les plus répandues (peur du jugement).

Pour éviter un tel comportement, vous aurez besoin de psychologie. Vous devez prouver à son cerveau de lézard que cela ne se produira pas (il ne sera pas jugé, humilié, tué, quoi que ce soit ...) en le désensibilisant aux revues de code.

L'une des méthodes les plus efficaces que j'ai trouvées pour débloquer quelqu'un est de lui demander de réviser votre code , avant de demander de réviser son code.

Au bout d'un moment, proposez- lui de lire son code pour en tirer des leçons et pourquoi pas proposer des améliorations. Lorsque vous trouvez quelque chose à changer, faites attention à ce que vous écrivez. Il comprendra qu'il n'y a rien à craindre, et il ne prendra que la partie positive du processus de révision: apprendre et augmenter ses connaissances .

J'essaierais de travailler en binôme - fais équipe avec quelqu'un qui déteste l'idée avec quelqu'un qui l'aime, et fais-leur passer en revue le code de l'autre pendant quelques semaines. Évidemment, cela peut ou peut ne pas aider, mais le fait d'être aux deux extrémités de l'examen donnera au moins une vue plus complète du processus. Avoir une paire de travail ensemble leur permettra de se familiariser avec le style de l'autre et les erreurs courantes et leur donnera le temps de s'entraider, plutôt que de se faire du caoutchouc. Cela peut également vous aider à promouvoir la programmation par paires dans votre environnement de travail, car je pense que vous pouvez voir une tendance croissante non seulement à revoir, mais à recoder ou même à planifier et à coder à partir de zéro.

Tant que les parties désintéressées sont prêtes à essayer, cela pourrait aider. S'ils refusent d'en tenir compte, il n'y a pas grand-chose que vous puissiez faire à ce sujet tant qu'ils font partie de l'équipe.

@ La réponse de Pierre est sur la bonne voie pour quelqu'un qui craint une révision du code. Je peux imaginer une autre situation. Un programmeur vedette qui estime qu'une révision de code est une perte de temps car le code atteint un niveau acceptable de qualité et d'exactitude. Dans ce cas, ils peuvent penser qu'une révision de code est une perte de temps et une chasse aux sorcières. (Il s'agit d'une recherche d'un problème lorsqu'il n'en existe pas.)

Dans ce cas, je réorienterais l'objectif de l'examen. Au lieu que la révision du code concerne la recherche de "problèmes" dans le code, traitez-le comme une recherche de cibles de refactorisation ou d'améliorations futures potentielles, ou de fonctionnalités de conception supplémentaires. De cette façon, le codeur et le réviseur sont impliqués dans le processus et nous espérons que ce codeur compétent aura l'impression que le temps est mis à profit.

Franchement, cette question n'a aucun sens si vous avez une boutique bien gérée:

1) Si cela fait partie du travail, vous devez le faire, ou vous êtes insoumis. Quelqu'un qui refuse catégoriquement de faire une partie du travail qu'il doit faire devrait être mis en boîte. La programmation est un métier et une profession - les examinateurs et les gestionnaires sont là pour aider à faire le travail, pas pour s'occuper des enfants gâtés (de tout âge).

2) Si vous avez un système de contrôle de source bien géré (ce qui est indispensable dans n'importe quel magasin de logiciels professionnel), leur code peut être révisé, qu'ils le veuillent ou non. Consultez donc leur code:

• Si c'est bon, informez-les et donnez-leur une tape dans le dos - cela encouragera la participation.

• Si ce n'est pas bon, informez-les également. Cela devrait avoir pour effet de les motiver à participer, afin de se défendre. Si ce n'est pas le cas, vous pouvez utiliser des mesures punitives: sanctions financières, rétrogradations, etc. Si, malgré vos efforts, cet employé ne parvient pas à se déplacer, IMO vous avez un mauvais employé et on devrait lui montrer la porte.

Ont-ils des expériences négatives dans des endroits où les révisions de code n'ont pas été effectuées correctement? Ils peuvent avoir des préoccupations légitimes.

S'ils ne voient absolument aucun mérite à l'exercice, demandez-leur d'être patient et de voir ce qui arrive à leur code et en particulier aux autres (s'ils pensent qu'ils sont parfaits) en conséquence.

L'examen du code «devrait» améliorer le développement, mais tant que vous n'avez pas un système qui fonctionne réellement, pourquoi quelqu'un devrait-il le faire?

Personnellement, il y a des combats qui ne peuvent tout simplement pas être gagnés avec 100% de la population.

Je peux voir suffisamment de raisons pour lesquelles la programmation par paires ne fonctionnerait pas lorsque quelqu'un est obligé de le faire.

Mais les revues de code sont différentes - elles changent votre productivité, pas nécessairement vos habitudes de travail.

La direction peut faire plusieurs choses pour réduire la résistance due à la productivité: 1) Accepter la réduction de vitesse pour tous les développeurs. 2) Fournir des outils appropriés pour gérer la gestion et la fusion de plusieurs versions en raison des cycles de révision (par exemple, permettre aux développeurs d'avoir un référentiel git local) 3) Appliquer une certaine forme de pression sociale ou autre pour assurer la distribution de la charge et la qualité et l'actualité des critiques.

S'ils le font, il est légitime d'exiger que tout le monde participe, à mon humble avis. La société pour laquelle je travaille maintenant force cela à l'échelle mondiale - vous ne pouvez tout simplement pas soumettre sans l'approbation du propriétaire. Et bien que cela ralentisse les choses, cela évite de nombreux accidents.

Nous avons utilisé des mesures techniques pour rendre la révision du code obligatoire.

La façon dont nous avons introduit la révision du code est que dans notre contrôle de code source, il est impossible de fusionner du code qui n'a pas été validé par quelqu'un d'autre que celui qui l'a poussé.

Tire-les

C'est aussi simple que cela - soit ils obtiennent un projet en solitaire, soit ils doivent y aller. Éloignez-les de votre équipe. Non seulement ils ne font pas leur part, ils érodent le moral et les pratiques de l'équipe.

Maintenant, s'il semble que vous devez licencier 50% de votre équipe, alors ...

Comprendre

Pourquoi certains refusent? N'ont-ils pas le temps? Sont-ils brûlés? Existe-t-il des avis sur quelque chose avec lequel ils n'ont aucune expérience? Pensent-ils que c'est une perte de temps, si oui pourquoi?

La méthodologie agile vous aidera ici - je suppose que vous travaillez constamment contre les silos (c.-à-d. Pour réduire le facteur bus), et les membres de votre équipe sont impliqués dans ce que font les autres.

Faites en sorte que les demandes de fusion individuelles soient assez petites. S'il s'agit de plus d'un écran de modifications, il a besoin d'un discours debout ou éclair pour expliquer ce qui est fait. Si c'est 10 pages, il a besoin d'une présentation avec des diapositives et des diagrammes d'architecture.

Est-ce que tout le monde en question travaille sur le même projet?

Le projet est-il déjà enfoui sous une montagne de dettes techniques?

Croient-ils au projet et à l'amélioration continue?