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

36

Eu encontrei uma pergunta (código cowboy na equipe), mas estava mais relacionado com "Ninja Coder", então o problema que eu tenho.

Eu tenho um membro da equipe que é um exemplo vivo e puro 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 recentemente interrompeu as revisões de código, os testes de unidade, os 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 de seu código. Eu não quero consertar seus insetos. E o gerenciamento é cego, ou não quer ver isso, ou talvez eles gostem da sua "velocidade".

Existe alguma maneira que eu (como seu colega mais novo por idade, não seu chefe) pode fazer algo sobre isso?

Como posso desarmar este codificador de cowboys?

Eu sinto que sou o último que realmente se importa com o projeto.

    
por Adronius 18.07.2012 / 17:26
fonte

5 respostas

21

Eu vejo algumas opções:

  • Aproxime-se do codificador com suas preocupações. Deve ser feito como uma crítica construtiva com pontos específicos. Antes de tomar medidas maiores, é apropriado levantar preocupações diretamente e em particular para dar à pessoa a oportunidade de mudar.
  • Reúna informações e estatísticas e traga para o gerenciamento. Gestão pode não parecer se importar, mas muitas vezes é importante fazer o esforço de qualquer maneira, caso isso funcione. Possíveis conseqüências negativas incluem a alienação de outras pessoas que não apreciam reclamações para a administração.
  • Encontre um colega do codificador cowboy e discuta em particular. Ele / ela pode ter uma chance melhor de fazer com que a pessoa ouça.
  • Peça para trabalhar em outro time. Não vai resolver o problema, mas você vai manter sua sanidade. No mínimo, sempre trabalhe da melhor maneira possível e não deixe que isso o atrapalhe.
  • Deixe a organização se ninguém escutar. Parece um ambiente ruim.
por 18.07.2012 / 17:45
fonte
6

He refuses to listen to the team, and he recently stopped code reviews, unit testing, sharing the implementation details...

As revisões de código não exigem necessariamente que o programador 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 por seus check-ins. Se você está preocupado com o código dele, essa é uma maneira fácil de encontrá-lo. Obtenha um histórico de diferenças, veja o que ele colocou e veja se alguma bandeira vermelha aparece em você. Pegue seus checkins rápido o suficiente e se você encontrar um problema, você pode reverter o commit e enviá-lo por e-mail para esse efeito. Você tem permissão para chamar os membros de sua equipe, mesmo como um codificador júnior, quando vir algo obviamente errado.

Yes, he "codes" fast, but his code is just a bug generator. Other team members and I are in a "bug fixing phase" and 80% of bugs comes from his code. I don't want to fix his bugs. And management is blind, or doesn't want to see this, or maybe they like his "speed".

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

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

E, no que diz respeito à "velocidade", a velocidade é a rapidez com que as coisas são "feitas" e não "concluídas" até que sejam feitas corretamente. Você pode colocá-lo para seus gerentes dessa maneira; considere um mecânico de automóveis que, quando o gerente pega seu BMW para obter uma troca de óleo, esquece de voltar a colocar o bujão de óleo e, como resultado, todo o novo óleo vaza antes mesmo de sair 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 seu carro atrapalhar a caminho de casa. Ele vai se importar que o mecânico tenha perdido um passo, que vai custar muito mais tempo e dinheiro para ter consertado. Agora, ele está pagando a um vaqueiro para fazer o trabalho muito rápido, e então ele está pagando ao resto da equipe uma quantia muito maior para entrar e refazer o trabalho corretamente. O que, realmente, é a vantagem de continuar deixando o vaqueiro fazer as coisas dele?

Is there any way that I (as his younger colleague by age, not his boss) can do something about it?

Ligue para ele. Quando você encontra 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ê foi ou será obrigado a fazer como resultado para consertar seu código quebrado.

I feel like I'm the last one who really cares about the project at all.

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

    
por 18.07.2012 / 20:39
fonte
5

Acesse o gerenciamento com suas estatísticas sobre quantos erros / problemas são provenientes desse desenvolvedor. Explique a eles que corrigir seus bugs afeta a produtividade da sua equipe. Se, de fato, 80% dos problemas vierem de uma pessoa, isso definitivamente precisa ser resolvido. Contanto que você explique à gerência em termos que eles possam concordar com (ou seja, "o tempo desperdiçado é dinheiro desperdiçado"), eles intervirão.

Além disso, esse desenvolvedor deve corrigir seus próprios erros / problemas, por isso pode ser útil atribuir esses problemas a eles. Sua equipe não deve cobrir essa pessoa.

    
por 18.07.2012 / 17:34
fonte
4

Is there any way that I (as his younger colleague by age, not his boss) can do something about it?

A pressão dos pares e liderar pelo exemplo são as únicas boas maneiras. As melhores maneiras são feitas pelo seu chefe / líder. Se você não é seu chefe / líder, fale com aqueles que são. Mas no final é o trabalho deles cuidar disso, não o seu. Certifique-se de que você está fazendo um bom trabalho e as coisas tendem a dar certo.

    
por 18.07.2012 / 17:45
fonte
0

He refuses to listen to the team, and he recently stopped code reviews, unit testing, sharing the implementation details...

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

    
por 18.07.2012 / 18:20
fonte