Como você desarma um codificador de cowboy? [fechadas]

Eu encontrei uma pergunta (código cowboy na equipe), mas estava mais relacionada ao "Ninja Coder" do que ao problema que tenho.

Eu tenho um membro da equipe que é um exemplo vivo de " Cowboy Coder ". Eu entendo que não se pode mudar as pessoas, mas é uma maneira de fazê-lo parar de se comportar como um "Cowboy Coder"?

Ele se recusa a ouvir a equipe e interrompeu recentemente as análises de código, o teste de unidade, o compartilhamento dos detalhes da implementação etc.

Sim, ele "codifica" rapidamente, mas seu código é apenas um gerador de bugs. Outros membros da equipe e eu estamos em uma "fase de correção de bugs" e 80% dos bugs vêm do código dele. Eu não quero consertar os erros dele. E a gerência é cega, ou não quer ver isso, ou talvez eles gostem da sua "velocidade".

Existe alguma maneira de eu (como seu colega mais jovem por idade, não seu chefe) fazer algo a respeito?

Como posso desarmar esse codificador de cowboy?

Sinto que sou o último que realmente se importa com o projeto.

Vejo algumas opções:

• Aborde o codificador com suas preocupações. Deve ser feito como crítica construtiva com pontos específicos. Antes de tomar medidas maiores, é apropriado levantar preocupações diretamente e em privado para dar à pessoa a oportunidade de mudar.
• Reúna informações e estatísticas e leve-as à gerência. A gerência pode não parecer se importar, mas muitas vezes é importante fazer o esforço de qualquer maneira, caso funcione. Possíveis consequências negativas incluem alienar outras pessoas que não apreciam reclamações para a gerência.
• Encontre um colega do programador de cowboys e discuta-o em particular. Ele / ela pode ter uma chance melhor de conseguir que a pessoa ouça.
• Peça para trabalhar em outra equipe. Não resolverá o problema, mas você manterá sua sanidade. No mínimo, sempre trabalhe da melhor maneira possível e não deixe que isso o arraste.
• Deixe a organização se ninguém ouvir. Parece um ambiente ruim.

Ele se recusa a ouvir a equipe e interrompeu recentemente as análises de código, o teste de unidade e o compartilhamento dos detalhes da implementação ...

As revisões de código não exigem necessariamente que o codificador envie o trabalho para revisão.

Uma maneira fácil de acompanhar o que ele faz é ficar de olho no histórico do VCS, procurando seus check-ins. Se você está preocupado com o código dele, é uma maneira fácil de encontrá-lo. Obtenha um histórico diferenciado, veja o que ele colocou e veja se alguma bandeira vermelha aparece em você. Pegue os checkins dele com rapidez suficiente e, se encontrar um problema, você poderá reverter o commit e enviá-lo por e-mail para esse efeito. Você pode chamar seus colegas de equipe, mesmo como programador júnior, quando vir algo obviamente errado.

Sim, ele "codifica" rapidamente, mas seu código é apenas um gerador de bugs. Outros membros da equipe e eu estamos em uma "fase de correção de bugs" e 80% dos bugs vêm do código dele. Eu não quero consertar os erros dele. E a gerência é cega, ou não quer ver isso, ou talvez eles gostem da sua "velocidade".

Código vem de requisitos. Os requisitos resultam em testes executáveis ​​que verificam se os requisitos foram atendidos. Esses testes podem ser mais detalhados e escritos antes que sejam feitas alterações para verificar se as alterações atendem aos requisitos (refator vermelho-verde; a essência do TDD).

Adicione uma métrica "cobertura de código" ao servidor de criação da sua equipe (espero que você tenha uma; se não, esse é seu primeiro problema). Simplesmente verificar se os testes de unidade são aprovados não detectará problemas com seu novo código não TDD, feito em áreas que não possuem testes de unidade. Depois de executar todos os testes de unidade, o servidor de compilação idealmente deveria ter executado todas as linhas de código, mas existem algumas coisas que você simplesmente não pode testar. Realisticamente, você ainda deve esperar uma cobertura de 95% ou melhor (ou excluir determinadas bibliotecas ou tipos de arquivos da cobertura). Mais cedo ou mais tarde, seu cowboy fará o check-in de algo que interrompe a construção porque ele caiu o nível de cobertura abaixo do limite, e você o chama.

E no que diz respeito à "velocidade", a velocidade é a rapidez com que as coisas são "feitas", e não são "feitas" até que sejam feitas corretamente. Você pode colocar isso para seus gerentes dessa maneira; considere um mecânico de automóveis que, quando o gerente leva o BMW para trocar o óleo, esquece de ligar novamente o cárter e, como resultado, todo o óleo novo vaza antes mesmo que ele saia da garagem. Claro, a troca de óleo levou apenas cinco minutos, mas o gerente não vai se importar com isso quando o motor do carro parar no caminho de casa. Ele vai se importar que o mecânico tenha perdido um passo, que lhe custará muito tempo e dinheiro adicionais para consertar. No momento, ele está pagando um cowboy para fazer o trabalho muito rápido, e então ele ' s pagar ao restante da equipe uma quantia muito maior para entrar e refazer o trabalho corretamente. Qual é realmente a vantagem de continuar deixando o cowboy fazer o que ele faz?

Existe alguma maneira de eu (como seu colega mais jovem por idade, não seu chefe) fazer algo a respeito?

Ligue para ele. Quando você encontrar algo que ele errou, mostre a ele como seu código está falhando, como ele poderia ter evitado o problema em primeiro lugar (incluindo design adequado, TDD, revisões de código) e o que você era ou será obrigado a fazer como resultado para corrigir seu código quebrado.

Sinto que sou o último que realmente se importa com o projeto.

klaxons tocando, luzes piscando, sirenes tocando - se você realmente sente que é a única pessoa que se importa com a qualidade do código produzido pela equipe, então há um problema SÉRIO. Se você sentir que está tentando arrastar toda a equipe chutando e gritando para a era da boa codificação, e é apenas muito peso para transportar, solte-o. Se houver outra equipe na empresa que esteja fazendo o que é certo, peça uma transferência, caso contrário, dê o fora.

Vá para o gerenciamento com suas estatísticas sobre quantos bugs / problemas estão surgindo desse desenvolvedor. Explique a eles que a correção dos erros afeta a produtividade da sua equipe. Se, de fato, 80% dos problemas vêm de uma pessoa, isso definitivamente precisa ser resolvido. Contanto que você o explique à gerência em termos com os quais eles possam concordar (por exemplo, "tempo perdido é dinheiro desperdiçado"), eles intervirão.

Além disso, esse desenvolvedor deve corrigir seus próprios bugs / problemas, portanto, pode ser útil atribuir esses problemas a eles. Sua equipe não deve estar cobrindo essa pessoa.

Existe alguma maneira de eu (como seu colega mais jovem por idade, não seu chefe) fazer algo a respeito?

A pressão dos colegas e a liderança pelo exemplo são os únicos bons caminhos. As melhores maneiras são feitas pelo seu chefe / líder. Se você não é o chefe / líder deles, converse com quem é. Mas, no final, é o trabalho deles cuidar disso, não o seu. Verifique se você está fazendo um bom trabalho e as coisas tendem a se resolver.

Ele se recusa a ouvir a equipe e interrompeu recentemente as análises de código, o teste de unidade e o compartilhamento dos detalhes da implementação ...

Você não possui um caminho documentado para o código por meio de revisão, teste e implementação? Caso contrário, você tem um problema maior. Se fizer isso, isso é algo que precisa ser escalado.