Avançar a revisão de código e a prática de testes unitários

15

Como uma equipe lidera o gerenciamento de um grupo de desenvolvedores sem experiência (e não vê necessidade) em revisão de código e teste de unidade, como você pode fazer a revisão de código e a prática de testes de unidade?

Como você vai criar um caminho para que a revisão de código e o teste de unidade se encaixem naturalmente no fluxo do desenvolvedor?

Uma das resistências dessas duas áreas é que "estamos sempre apertados na linha de dados, então não há tempo para revisão de código e testes de unidade".

Outra resistência à revisão de código é que atualmente não sabemos como fazê-lo. Devemos revisar o código a cada check-in ou revisar o código em uma data específica?

    
por Graviton 11.02.2011 / 07:25
fonte

4 respostas

16

Os membros da sua equipe realmente concordam que as revisões de código e os testes de unidade são boas coisas, mas não há tempo para isso?

Ou eles tentam rejeitar a ideia com essa desculpa?

No primeiro caso, a solução é Começar a fazer isso agora . (OK, se você estiver nos últimos dias antes de um grande marco, talvez você possa esperar até depois - mas não mais). Tivemos essa situação em um local de trabalho anterior, onde eu era Engenheiro de Qualidade, responsável por melhorar as práticas de codificação e qualidade geral. Continuamos adiando o início das revisões de código até a próxima semana. Um dia, percebi que estamos fazendo isso há um mês, e provavelmente continuaremos até o fim dos tempos, a menos que eu tente algo diferente. Então eu anunciei a primeira revisão de código para aquela semana. Eu disse aos caras "não há problema se for imperfeito, ou se não sabemos exatamente o que fazer ainda - vamos apenas começar a fazer, ver como funciona e melhorar as coisas à medida que aprendemos". Funcionou, pelo menos até eu deixar a empresa.

No segundo caso, você pode precisar de mais educação e discussão aberta com a equipe. Discuta os problemas de qualidade do código, pergunte o que eles eles veem como problemas no processo de desenvolvimento (ou falta dele) / no código / teste etc. E debater juntos sobre como resolver estes . O objetivo final não é necessariamente fazer revisões de código - elas são apenas meios, enquanto o objetivo é melhorar o processo de desenvolvimento e a qualidade de sua produção. Pode muito bem acontecer que existam outras questões mais dolorosas que poderiam ser melhoradas mais facilmente, trazendo mais benefícios mais rapidamente; então pegue estes primeiro. Podem até ser mudanças triviais no ambiente ou no processo; tudo isso irá melhorar o moral da equipe, construir confiança mútua e ajudar o elo da equipe.

A questão é: você não pode forçar a qualidade a ninguém - você só pode remover os obstáculos da criação de qualidade . Ao impor regras rígidas e práticas obrigatórias sem o consenso prévio da equipe, você pode alienar a equipe e, em última análise, impedir a melhoria de qualidade que está buscando. OTOH por discussão aberta e com o objetivo de concordar sobre quais são os problemas mais prementes para a equipe e como melhorar a situação, é mais provável que você obtenha o apoio da equipe. Isso fará uma diferença crucial na manutenção da melhoria da qualidade a longo prazo.

    
por 11.02.2011 / 09:24
fonte
5

O problema clássico. Nunca há tempo suficiente para fazer o certo, sempre tempo suficiente para refazer o trabalho. Até que as pessoas comecem a fazer as melhores práticas, nunca haverá tempo suficiente para as melhores práticas. Particularmente desde que as vitórias são invisíveis para as pessoas fora do desenvolvimento.

A chave para a revisão de código é que você deseja revisar o menor código possível, o mais imediatamente possível. Dessa forma, é mais fácil obter tempo para analisá-lo, o código está fresco na mente das pessoas e a implementação das melhorias sugeridas será mais fácil. No extremo você quer rever cada check-in. Uma boa ferramenta para automatizar isso é link . É uma variante da ferramenta que o Google usa internamente para forçar a revisão de código a acontecer a cada check-in.

O desafio da revisão de código foi descrito há décadas no clássico The Psychology of Computer Programming . O problema é que os programadores tendem a amarrar sua auto-imagem às suas habilidades de programação. O que significa que, a qualquer momento em que os programadores são confrontados com evidências de que suas habilidades não estão à altura, há uma tendência a levá-lo para o lado pessoal. Isso pode causar sérios conflitos. Se você pegar o clássico Rapid Development de Steve McConnell , ele oferece várias sugestões de como configurar um processo de revisão de código que reduz as chances de tal conflito. (Um elemento-chave é garantir que a administração nunca tenha qualquer envolvimento no processo.) Observe que isso reduz as chances de conflito, mas não impede que conflitos aconteçam.

Dito isto, os benefícios superam os custos. Apenas para citar uma métrica, a IBM descobriu que a revisão de código era o dólar por dólar, a maneira mais eficaz de encontrar e eliminar bugs. Isso não substitui seu departamento de QA por nenhum meio. Mas isso resulta em muito menos problemas para eles encontrarem. E isso é antes de você entrar em benefícios envolvendo o quanto ele acelera o aprendizado, espalha conhecimento, etc.

    
por 11.02.2011 / 08:57
fonte
3

Não lhes dê a opção. Faça testes e avaliações obrigatórios. Se eles não cooperarem, você pode recorrer a algumas táticas hardline, como recusar promoções não testadas ou não revisadas. Se as coisas estiverem realmente ruins, atire no seu pior criminoso.

Eu tenho visto casos em que uma equipe está sempre atrasada porque está sempre corrigindo bugs que deveriam ter sido detectados por testes e resenhas. Um pouco mais de trabalho na frente economiza muito mais a longo prazo, e quanto mais cedo você alinhar sua equipe, melhor sua equipe terá.

Infelizmente, isso pode levar tempo para realmente ver os resultados. Para encorajar a prática, você pode começar a mapear a taxa de relatórios de bugs, o tempo médio para corrigir bugs e a taxa de implementação de recursos. Eu geralmente acho que depois de seis meses de testes e avaliações, essas métricas vão melhorar e sua equipe finalmente conseguirá.

    
por 11.02.2011 / 08:42
fonte
1

A introdução do tdd contra a vontade dos desenvolvedores é dificultada. É uma maneira difícil de aprender a amar o tdd.

Como tdd é mais eficiente em um campo verde (ou difícil, caro, ineficiente se os testes forem posteriores), eu começaria com uma pequena equipe que implementasse algo novo. Se você encontrar dois develloppers na equipe que são menos opostos ao tdd do que os outros que é um bom ponto de partida. lembre-se de que a produtividade dos desenvolvedores de tdd sofrerá enquanto eles não forem experientes no tdd.

Esse desenvolvimento do tdd é um bom ponto de partida para uma visualização de código. Discuta como o tdd influenciou a arquitetura do programa e como isso facilita a manutenção do software.

    
por 11.02.2011 / 09:27
fonte