Revisão avançada do código e prática de teste de unidade

Como líder de equipe, gerenciando um grupo de desenvolvedores sem experiência (e sem necessidade) em revisão de código e teste de unidade, como você pode avançar na prática de revisão de código e teste de unidade?

Como você criará uma maneira de que a revisão de código e o teste de unidade se ajustem naturalmente ao fluxo do desenvolvedor?

Uma das resistências dessas duas áreas é que "estamos sempre próximos da linha de dados, portanto não há tempo para revisão de código e teste 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 revisá-lo em uma data especificada?

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

Ou eles apenas tentam rejeitar a idéia com essa desculpa?

No primeiro caso, a solução é começar a fazê-lo agora . (OK, se você está nos últimos dias antes de um marco importante, talvez 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 o fazemos há um mês ou mais e provavelmente continuará até o fim dos tempos, a menos que tente algo diferente. Então, anunciei a primeira revisão de código daquela semana. Eu disse aos rapazes "não há problema se será imperfeito, ou se ainda não sabemos exatamente o que fazer - apenas começaremos a fazê-lo, veremos como vai 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 questões de qualidade de código, pergunte a elas o que elas vêem como problemas no processo de desenvolvimento (ou na falta dela) / no código / teste etc. E faça um brainstorming sobre como resolvê-las . 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 saída. Pode acontecer que outras questões mais dolorosas possam ser melhoradas com mais facilidade, trazendo mais benefícios mais rapidamente; depois leve-os primeiro. Eles podem até ser mudanças triviais no ambiente ou no processo; tudo isso irá melhorar o moral da equipe, criar confiança mútua e ajudar o vínculo da equipe.

O ponto principal é que você não pode impor 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, finalmente, impedir a melhoria da qualidade que deseja. OTOH por meio de uma discussão aberta e buscando um acordo sobre quais são os problemas mais urgentes para a equipe e como melhorar a situação, é mais provável que você obtenha apoio da equipe. Isso fará uma diferença crucial no acompanhamento da melhoria da qualidade a longo prazo.

O problema clássico. Nunca há tempo suficiente para fazê-lo corretamente, sempre tempo suficiente para refazer o trabalho. Até que as pessoas comecem a praticar as melhores práticas, nunca parecerá haver tempo suficiente para praticá-las. Especialmente porque 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 mínimo de código possível, o mais imediatamente possível. Dessa forma, é mais fácil ter tempo para revisá-lo, o código está atualizado na mente das pessoas e a implementação de melhorias sugeridas será mais fácil. No extremo, você deseja revisar cada check-in. Uma boa ferramenta para automatizar isso é http://code.google.com/appengine/articles/rietveld.html . É uma variante da ferramenta que o Google usa internamente para forçar a revisão de código a cada check-in.

O desafio da revisão de código foi descrito décadas atrás no clássico The Psychology of Computer Programming . O problema é que os programadores tendem a vincular sua auto-imagem a suas habilidades de programação. O que significa que, sempre que os programadores são confrontados com evidências de que suas habilidades não são adequadas, há uma tendência a considerá-las pessoalmente. Isso pode causar sérios conflitos. Se você escolher 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 gerência nunca tenha nenhum envolvimento no processo.) Observe que isso reduz as chances de conflito, mas não impede que o conflito aconteça.

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 dólar por dólar, a maneira mais eficaz de encontrar e eliminar bugs. Isso não substitui seu departamento de controle de qualidade por qualquer meio. Mas isso resulta em muito, muito menos problemas para eles encontrarem. E isso é antes de você obter benefícios que envolvem o quanto acelera o aprendizado, espalha conhecimento, etc.

Não dê a eles a opção. Faça testes e revisões obrigatórios. Se eles não cooperarem, você pode recorrer a algumas táticas básicas, como recusar promoções não testadas ou não revisadas. Se as coisas estiverem realmente ruins, demitir seu pior agressor.

Vi casos em que uma equipe está sempre atrasada porque está sempre corrigindo bugs que deveriam ter sido detectados por testes e revisões. Um pouco mais de trabalho inicial economiza muito mais a longo prazo, e quanto mais cedo você alinhar sua equipe, melhor será sua equipe.

Infelizmente, isso pode levar tempo para realmente ver os resultados. Para incentivar a prática, você pode começar a traçar a taxa de relatórios de bugs, tempo médio para correção de bugs e taxa de implementação de recursos. Normalmente, acho que após cerca de seis meses de testes e análises, essas métricas melhoram e sua equipe finalmente as obtém.

Introduzir o tdd contra a vontade dos desenvolvedores é difícil. É uma maneira difícil de aprender a amar tdd.

Como o tdd é mais eficiente em um campo verde (ou difícil, dispendioso e ineficiente se os testes forem realizados após o jogo), eu começaria com uma pequena equipe que implementa algo novo. Se você encontrar dois desenvolvedores na equipe que são menos opostos ao tdd do que os outros, esse é um bom ponto de partida. lembre-se de que a produtividade dos desenvolvedores de tdd sofrerá enquanto eles não tiverem experiência com tdd.

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