Como lidar com alguém que não gosta da ideia de revisão de código?

Obviamente, se a gerência dedica tempo à revisão de códigos, todos precisam fazer isso.

Mas sempre existem aqueles caras (ou moças) que resistem a cada grama de seu ser.

Como você gerencia efetivamente lidar com esse cenário ao lidar com ele como revisor?

Ele resiste por causa do medo . Esse condicionamento pode ser o resultado de experiências ruins antes de ser revisado, quando criança, na escola, no trabalho ou até em sua equipe atual. Em nossas sociedades modernas, é muito comum confundir a produção de alguém com seu valor como ser humano. É por isso que as revisões no trabalho não são bem percebidas. É também por isso que falar em público em uma das fobias mais disseminadas (medo de julgamento).

Para evitar esse comportamento, você precisará de alguma psicologia. Você deve provar ao cérebro de um lagarto que isso não vai acontecer (ele não será julgado, humilhado, morto, nada ...) dessensibilizando -o a codificar revisões.

Um dos métodos mais eficazes que encontrei para desbloquear alguém é pedir que ele revise seu código , antes de pedir para revisá-lo.

Depois de um tempo, proponha que ele leia seu código para aprender com ele e por que não sugerir melhorias. Quando encontrar algo para mudar, tenha cuidado com o que escreve. Ele entenderá que não há nada a temer e tomará apenas a parte positiva do processo de revisão: aprendendo e aumentando seu conhecimento .

Eu tentava trabalhar em pares - junte alguém que odeie a idéia com alguém que goste e peça para que revisem o código um do outro por algumas semanas. Obviamente, isso pode ou não ajudar, mas estar nos dois extremos da revisão dará pelo menos uma visão mais detalhada do processo. Ter um par trabalhando em conjunto permitirá que eles se familiarizem com o estilo um do outro e com os erros comuns e dará a eles tempo para realmente ajudar um ao outro a melhorar, em vez de usar o carimbo de borracha. Isso também pode ajudá-lo a promover a programação em pares no seu ambiente de trabalho, pois acho que você poderá ver uma tendência crescente não apenas para revisar, mas para recodificar ou até planejar e codificar do zero.

Enquanto as partes desinteressadas estiverem dispostas a tentar, isso pode ajudar. Se eles se recusarem a considerá-lo, não há muito o que fazer, desde que estejam na equipe.

A resposta de @ Pierre está no caminho certo para quem teme uma revisão de código. Eu posso imaginar outra situação. Um programador em estrela que sente uma revisão de código é um desperdício de tempo, porque esse código atinge um padrão aceitável de qualidade e correção. Nesse caso, eles podem sentir que uma revisão de código é uma perda de tempo e uma caça às bruxas. (Essa é uma busca por um problema quando não existe.)

Nesse caso, eu reorientaria o objetivo da revisão. Em vez de a revisão do código ser sobre como encontrar "problemas" no código, trate-o como uma busca por destinos de recondicionamento ou possíveis aprimoramentos futuros ou recursos adicionais de design. Dessa forma, tanto o codificador quanto o revisor estão envolvidos no processo e, esperançosamente, esse codificador capaz parecerá que há tempo sendo aproveitado.

Francamente, essa pergunta não faz sentido se você tiver uma loja bem gerenciada:

1) Se faz parte do trabalho, você deve fazê-lo ou é insubordinado. Alguém que se recusa veementemente a fazer parte do trabalho que é obrigado a fazer deve ser enlatado. A programação é um ofício e uma profissão - revisores e gerentes estão lá para ajudar a fazer o trabalho, não para lidar com crianças mimadas (de qualquer idade).

2) Se você possui um sistema de controle de origem bem gerenciado (que é obrigatório em qualquer loja de software profissional), o código pode ser revisado, gostando ou não. Então revise o código deles:

• Se estiver bom, notifique-os e dê um tapinha nas costas - isso incentivará a participação.

• Se não der certo, informe-os também. Isso deve ter o efeito de motivá-los a participar, a fim de se defender. Caso contrário, você pode usar medidas punitivas: penalidades financeiras, rebaixamentos de status etc. Se, apesar de seus esforços, esse funcionário não aparecer, IMO você tem um funcionário ruim e deve ser mostrada a porta.

Eles têm algumas experiências negativas em locais onde as revisões de código não foram feitas corretamente? Eles podem ter preocupações legítimas.

Se eles absolutamente não vêem mérito no exercício, peça que sejam pacientes e veja o que acontece com seu código e, especialmente, com os outros (se eles acham que são perfeitos) como resultado.

A Revisão de Código 'deve' melhorar o desenvolvimento, mas até que você tenha um sistema que realmente funcione, por que alguém iria querer fazer isso?

Pessoalmente, existem algumas lutas que simplesmente não podem ser vencidas com 100% da população.

Eu posso ver razões suficientes pelas quais a programação em pares não funcionaria quando alguém é forçado a fazê-lo.

Mas as revisões de código são diferentes - elas alteram sua produtividade, não necessariamente seus hábitos de trabalho.

O gerenciamento pode fazer várias coisas para reduzir a resistência devido à produtividade: 1) Aceite a redução de velocidade para todos os desenvolvedores. 2) Forneça ferramentas apropriadas para lidar com o gerenciamento e a mesclagem de várias versões devido a ciclos de revisão (por exemplo, permitindo que os desenvolvedores tenham um repositório git local) 3) Aplique alguma forma de pressão social ou outra para garantir a distribuição de carga, qualidade e pontualidade de revisões.

Se eles fizerem isso, é legítimo exigir que todos participem, IMHO. A empresa em que trabalho agora força isso globalmente - você simplesmente não pode enviar sem a aprovação de um proprietário. E enquanto isso atrasa as coisas, evita muitos acidentes.

Usamos medidas técnicas para tornar obrigatória a revisão de código.

A maneira como introduzimos a revisão de código é que, em nosso controle de origem, é impossível mesclar código que não foi assinado por outra pessoa que não o empurrou.

Despedi-los

É simples assim - eles conseguem um projeto solitário ou precisam ir. Afaste-os de sua equipe. Eles não apenas não estão fazendo sua parte, mas também desgastam o moral e as práticas da equipe.

Agora, se parece que você precisa demitir 50% do seu time, então ...

Compreendo

Por que alguns recusam? Eles não têm tempo? Eles estão queimados? Existem críticas sobre algo com o qual não têm experiência? Eles acham que é uma perda de tempo, se sim, por quê?

A metodologia ágil ajudará aqui - presumo que você trabalhe constantemente contra silos (ou seja, para reduzir o fator de barramento), e os indivíduos de sua equipe estejam envolvidos no que os outros fazem.

O trabalho para garantir que as solicitações de mesclagem individuais sejam muito pequenas. Se houver mais de uma tela de alterações, ele precisará de uma conversa em pé ou relâmpago para explicar o que está sendo feito. Se tiver 10 páginas, precisará de uma apresentação com slides e diagramas de arquitetura.

Todos em questão trabalham no mesmo projeto?

O projeto já está enterrado sob uma montanha de dívida técnica?

Eles acreditam no projeto e na melhoria contínua?