O que você faz com um desenvolvedor que não testa seu código? [fechado

https://stackoverflow.com/questions/139228

02-07-2019
|

Pergunta

Um de nossos desenvolvedores está escrevendo continuamente o código e colocando -o no controle de versão sem testá -lo. A qualidade do nosso código está sofrendo como resultado.

Além de se livrar do desenvolvedor, como posso resolver esse problema?

EDITAR

Eu conversei com ele sobre o número de vezes e até dei a ele aviso por escrito

Solução

Se você executar sistematicamente Revisões de código Antes de permitir que um desenvolvedor cometa o código, bem, seu problema é resolvido principalmente. Mas esse não parece ser o seu caso, então é isso que eu recomendo:

Fale com o desenvolvedor. Discuta as consequências para outras pessoas da equipe. A maioria dos desenvolvedores deseja ser reconhecida por seus pares, então isso pode ser suficiente. Também aponte que é muito mais fácil corrigir bugs no código que está fresco em sua mente do que o código de uma semana. Esta parte faz sentido se você tiver alguma forma de Código OwnShip no lugar.
Se isso não funcionar depois de algum tempo, tente implementar uma política que tornará o código de buggy cometer desagradável para o autor. Uma maneira popular é tornar a pessoa que quebrou a construção responsável pelas tarefas de criar a próxima. Se o seu processo de construção estiver totalmente automatizado, procure outra tarefa servil para cuidar. Essa abordagem tem o benefício adicional de não identificar ninguém em particular, tornando -o mais aceitável para todos.
Use medidas disciplinares. Dependendo do tamanho da sua equipe e da sua empresa, eles podem assumir muitas formas.
Disparar o desenvolvedor. Há um custo associado a manter maçãs ruins. Quando você chega até aqui, o desenvolvedor não se importa com seus colegas desenvolvedores e você já tem um problema de pessoas em suas mãos. Se o ambiente de trabalho for envenenado, você poderá perder muito mais - em termos de produtividade e em termos de pessoas - do que este único desenvolvedor ruim.

Outras dicas

Se você pode fazer análises de código - esse é um lugar perfeito para pegá -lo.

Exigimos críticas antes de se fundir ao tronco de iteração, então normalmente tudo é capturado na época.

Espancamentos rituais! Para cada bug, um chicote do chicote!

(Uma piada para quem não entende)

Como desenvolvedor que raramente testa seu próprio código, posso lhe dizer a única coisa que me fez mudar lentamente meu comportamento ...

Visibilidade

Se o ambiente permitir empurrar o código, aguardando os usuários para encontrar problemas e, basicamente, perguntando "que tal agora?" Depois de fazer uma alteração no código, não há incentivo real para testar suas próprias coisas.

As análises de código e a colaboração incentivam você a trabalhar para tornar um produto de qualidade muito mais do que se você estivesse apenas entregando 'widget x' enquanto seus colegas de trabalho trabalham em 'widget y' e 'widget z'

Quanto mais visível o seu trabalho, maior a probabilidade de você se preocupar com o funcionamento.

Revisão de código. Coloque todos os seus desenvolvedores em uma sala toda segunda-feira de manhã e peça que eles tragam sua realização mais orgulhosa baseada em código da semana anterior junto com eles para a reunião.

Deixe -os levar os holofotes e ficar empolgados em explicar o que fizeram. Peça -lhes que tragam cópias do código para que outros desenvolvedores possam ver do que estão falando.

Começamos esse processo há alguns meses e é surpreendente ver a quantidade de verificações de qualidade subconsciente que ocorrem. Afinal, se os desenvolvedores forem convidados a falar sobre o que estão mais empolgados, estarão totalmente felizes em mostrar às pessoas seu código. Então, outros desenvolvedores verão os erros de qualidade e discutirão publicamente por que estão errados e como o código deve realmente ser escrito.

Se isso não conseguir que seu desenvolvesse o código de qualidade, ele provavelmente não se encaixa bem na sua equipe.

Faça parte de seus objetivos anuais de revisão. Se ele não conseguir, nenhum aumento salarial.

Às vezes, embora você precise aceitar que alguém simplesmente não é adequado para sua equipe/ambiente, deve ser o último recurso e pode ser difícil de lidar, mas se você esgotou todas as outras opções, pode ser a melhor coisa a longo prazo .

Diga ao desenvolvedor que você gostaria de ver uma mudança em suas práticas dentro de duas semanas ou iniciará o procedimento disciplinar da sua empresa. Ofereça o máximo de ajuda e assistência possível, mas se você não puder mudar essa pessoa, ele não é adequado para sua empresa.

Usando controle de cruzeiro ou uma ferramenta semelhante, você pode fazer o checkins acionar automaticamente um teste de construção e unidade. Você ainda precisaria garantir que haja testes de unidade para qualquer nova funcionalidade que ele acrescenta, o que você pode fazer olhando seus checkins. No entanto, esse é um problema humano, portanto, uma solução técnica só pode ir tão longe.

Por que não apenas falar com ele? Ele provavelmente não vai te morder.

Faça dele "cuidar" da construção e tornar -se o gerente de construção. Isso lhe dará menos tempo para desenvolver código (aumentando assim o desempenho de todos) e ensinar -lhe por que uma boa construção é tão necessária.
Aplicar casos de teste - O código não pode ser enviado sem casos de teste de unidade. Modifique o sistema de compilação para que, se os casos de teste não compilarem e executarem corretamente, ou não existirem, todo o verificação de tarefas será negado.

-Adão

Publique estatísticas sobre cobertura do código de teste por desenvolvedor, isso seria depois de falar com ele.

Aqui estão algumas idéias de uma favela do mar.

Intro
   What shall we do with a drunken sailor, (3×)
   Early in the morning?
Chorus
   Wey–hey and up she rises, (3×)
   Early in the morning!
Verses
   Stick him in a bag and beat him senseless, (3×)
   Early in the morning!
   Put him in the longboat till he’s sober, (3×)
   Early in the morning!

etc. Substitua o "marinheiro bêbado" por um "desenvolvedor desleixado".

Dependendo do tipo de sistema de controle de versão que você está usando, você pode configurar políticas de check-in que forçam o código a aprovar determinados requisitos antes de poder fazer o check-in. Se você estiver usando um SYTEM Like Team Foundation Server, ele oferece a capacidade de especificar requisitos de cobertura de código e teste de unidade para check-ins.

Você sabe, esta é uma oportunidade perfeita para evitar destacá-lo (embora eu concorde que você precisa conversar com ele) e implementar um processo de teste primeiro internamente. Se as regras não forem claras e as expectativas são conhecidas por todos, descobri que o que você descreve não é tão incomum. Acho que fazer o esquema de desenvolvimento de teste funciona bem para mim e melhora a qualidade do código.

Eles podem estar excessivamente focados na velocidade e não na qualidade.

Isso pode tentar algumas pessoas a apressar questões para limpar sua lista e ver o que volta aos relatórios de bugs posteriormente.

Para corrigir esse equilíbrio:

atribua apenas alguns itens por vez em seu sistema de rastreamento de problemas,
Revisão do código e teste qualquer coisa que eles "concluíram" o mais rápido possível, para que volte a eles imediatamente se houver algum problema
converse com eles sobre suas expectativas sobre quanto tempo um item levará para fazer corretamente

A programação de pares é outra possibilidade. Se ele está com outro desenvolvedor qualificado na equipe que morre atende aos padrões de qualidade e conhece o procedimento, isso tem alguns benfits:

Com um desenvolvedor experiente por cima do ombro, ele aprenderá o que é esperado dele e verá a diferença entre seu código e código que atende às expectativas
O outro desenvolvedor pode fazer cumprir uma primeira política de teste: não permitir que o código seja escrito até que os testes sejam escritos para isso
Da mesma forma, o outro desenvolvedor pode verificar se o código está à altura antes de ser verificado, reduzindo o número de check-ins ruins

É claro que tudo isso exige que a empresa e os desenvolvedores sejam receptivos a esse processo que eles podem não ser.

Parece que as pessoas criaram muitas respostas imaginativas e desonestas para esse problema. Mas o fato é que este não é um jogo. A criação de elaborados sistemas de pressão dos colegas para "nome e envergonhar" não vai chegar à raiz do problema, ou seja. Por que ele não está escrevendo testes?

Eu acho que você deveria ser direto. Eu sei que você diz que falou com ele, mas você já tentou descobrir Por quê Ele não está escrevendo testes? Claramente neste momento ele sabe que ele deve Seja, certamente deve haver alguma razão pela qual ele não está fazendo o que lhe foi dito para fazer. É preguiça? Procrastinação? Os programadores são famosos por seus egos e opiniões fortes - talvez ele esteja convencido por algum motivo de que os testes sejam uma perda de tempo ou que seu código seja sempre perfeito e não precisa de testes. Se ele é um programador imaturo, ele pode não entender completamente as implicações de suas ações. Se ele é "muito maduro", ele pode estar muito definido em seus caminhos. Seja qual for o motivo, aborde -o.

Se tudo se resume a uma questão de opinião, você precisa fazê -lo entender que ele precisa deixar de lado sua opinião pessoal e apenas seguir as regras. Deixar claro que se ele não puder ser confiável Para seguir as regras, ele será substituído. Se ele ainda não o fizer, faça exatamente isso.

Uma última coisa - documente todas as suas discussões, juntamente com quaisquer problemas que ocorram como resultado de suas mudanças. Se for o pior, você poderá ser forçado a justificar suas decisões; nesse caso, ter evidências documentais certamente será inestimável.

Coloque -o em seu próprio ramo de desenvolvimento e apenas traga suas coisas para o porta -malas quando souber que é completamente testado. Este pode ser um local onde uma ferramenta de gerenciamento de controle de origem distribuída como Git ou Mercurial se destacaria. Embora com o aumento do suporte de ramificação/mesclagem no SVN, você pode não ter muitos problemas para gerenciá -lo.

EDITAR

Isso é apenas se você não puder se livrar dele ou fazê -lo mudar seus caminhos. Se você simplesmente não consegue fazer com que esse comportamento pare (mudando ou disparando), o melhor que você pode fazer é amortecer o restante da equipe dos maus efeitos de sua codificação.

Se você estiver em um local onde pode afetar as políticas, faça algumas alterações. Faça revisões de código antes de fazer check -in e fazer o teste parte do ciclo de desenvolvimento.

Parece bastante simples. Faça um requisito e, se ele não puder fazê -lo, substitua -o. Por que você o guardaria?

Eu geralmente não defendo isso, a menos que tudo mais falhe ...

Às vezes, um gráfico publicamente displayed de contagem de insetos por desenvolvedor pode aplicar pressão de colegas suficientes para obter resultados favoráveis.

Experimente a cenoura, faça um jogo divertido.
Por exemplo, o plugin de jogo de integração contínuo para Hudson
http://wiki.hudson-ci.org/display/hudson/the+continuous+integration+game+plugin

Coloque seus desenvolvedores nas filiais do seu código, com base em alguma lógica, por recurso, por correção de bug, por equipe de desenvolvimento, qualquer que seja. Então os check-ins ruins são isolados para esses ramos. Quando chegar a hora de fazer uma construção, fundir -se a uma filial de teste, encontrar problemas, resolver e, em seguida, mesclar sua liberação de volta a uma filial principal.

Ou remova os direitos de comprometimento desse desenvolvedor e peça que eles enviem seu código para um desenvolvedor mais jovem para revisão e teste antes que ele possa ser comprometido. Isso pode motivar uma mudança no procedimento.

Você pode montar um relatório com erros encontrados no código com o nome do programador responsável por esse software.

Se ele é uma pessoa razoável, discuta o relatório com ele.

Se ele se importa com sua "reputação", publique o relatório regularmente e disponibilizá -lo para todos os seus colegas.

Se ele apenas outa a "autoridade", faça o relatório e escalie a questão para seu gerente.

De qualquer forma, eu já vi que, quando as pessoas são informadas de como parecem ruins de fora, elas mudam seu comportamento.

Ei, isso me lembra de algo que li no xkcd :)

Você está se referindo à redação de testes de unidade automatizada ou unidade manualmente antes do check-in?

Se sua loja não escrever testes automatizados, a verificação dele de código que não funciona é imprudente. Está impactando a equipe? Você tem um departamento de controle de qualidade formalizado?

Se todos estão criando testes de unidade automatizados, sugiro que parte do seu processo de revisão de código inclua os testes de unidade também. Ficará óbvio que o código não é aceitável de acordo com seus padrões durante sua revisão.

Sua pergunta é bastante ampla, mas espero ter fornecido alguma direção.

Eu concordo com Phil que o primeiro passo é conversar individualmente com ele e explicar a importância da qualidade. A baixa qualidade geralmente pode estar ligada à cultura da equipe, departamento e empresa.

Faça casos de teste executados um dos entregas antes que algo seja considerado "feito".

Se você não executou casos de teste, o trabalho não está completo e, se o prazo passa antes de você ter a execução do caso de teste documentada, ele não entregou a tempo, e as consequências seriam as mesmas como se ele tivesse não concluiu o desenvolvimento.

Se a cultura da sua empresa não permitiria isso, e valoriza a velocidade da precisão, essa é provavelmente a raiz do problema, e o desenvolvedor está simplesmente respondendo aos incentivos que estão em vigor - ele está sendo recompensado por fazer muito Coisas semi-nascidas em vez de menos coisas corretamente.

Faça a pessoa limpar as latrinas. Trabalhou no exército. E se você trabalha em um grupo com indivíduos que comem muita comida indiana, não demorará muito para que eles caíssem na fila.

Mas sou só eu ...

Toda vez que um desenvolvedor verifica algo que não compila, coloque algum dinheiro em uma jarra. Você pensará duas vezes antes de verificar então.

Infelizmente, se você já falou com ele muitas vezes e deu a ele avisos escritos, eu diria que é hora de eliminá -lo da equipe.

Você pode encontrar algumas respostas úteis aqui: Como fazer os programadores juniores escreverem testes?

Licenciado em: CC-BY-SA com atribuição

Não afiliado a StackOverflow