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.