O que deve vir primeiro: teste ou revisão de código?

Eu sou um iniciante em programação de padrões de design e ciclos de vida e estava pensando: o que deve vir primeiro, a revisão ou o teste de código, a respeito de que eles são feitos por pessoas separadas?

Por um lado, por que se preocupar em revisar o código se ninguém verificou se ele sequer funciona? Do outro, alguns erros podem ser encontrados com antecedência, se você fizer a revisão antes do teste.

Qual abordagem é recomendada e por quê?

Primeiro, teste de unidade do desenvolvedor, depois revisão de código e teste de controle de qualidade. Às vezes, a revisão do código ocorre antes do teste de unidade, mas geralmente apenas quando o revisor está realmente inundado e é a única vez que ele ou ela pode fazê-lo.

Nosso padrão é fazer a revisão do código antes do produto entrar no controle de qualidade. A razão para isso é que, uma vez que o produto foi testado e verificado, há menos incentivo para refatorar e modificar o código internamente. Teria que ser testado novamente. Observe que também fazemos testes de unidade na maioria dos casos.

Idealmente, em um mundo ágil, ambos :)

O desenvolvimento orientado a testes é um método que incentiva o desenvolvimento de testes de unidade antes da gravação do código real - dessa forma, você pode capturar a especificação no código e escrever testes que passam nos testes. Depois disso, testes de integração automatizados que garantem que todos os diferentes componentes se encaixam são uma coisa boa para garantir ainda mais que a funcionalidade do seu aplicativo corresponda ao esperado.

Quanto às revisões de código, a programação em pares é uma maneira útil de ter outra mente negligenciando seu código enquanto você o escreve. No entanto, isso não é necessariamente uma abordagem prática. A maneira como funciona na minha empresa atual é que o código é revisado após ter sido testado na máquina pessoal do desenvolvedor, mas antes de ter sido implantado em um servidor de desenvolvimento compartilhado.

A revisão do código é feita para "polir" as coisas que já funcionam, para garantir que o código tenha o nível de qualidade desejado e atenda às diretrizes de código definidas pela empresa.

A revisão de código também pode ocorrer como parte da futura atividade geral de otimização, na qual você refatora e aprimora o código antigo.

Se você pratica a revisão do código antes de fazer o check-in, a revisão do código fica entre dois estágios de teste: você como desenvolvedor testa seu código primeiro, seu colega faz a revisão do código, faz o check-in e, posteriormente, testadores dedicados realizarão testes individuais e individuais mais detalhados. testes de integração.

Teste primeiro. Teste por último. Teste, teste, teste.

A revisão de código é boa de se ter. Mas difícil - pode ser um processo doloroso se personalidades envolvidas ou opiniões divergentes.

O teste é muito claro: funciona ou não. Então teste, teste, teste! E revisão de código, se possível.

No meu último trabalho, tivemos três tipos diferentes de revisões de código que faríamos em diferentes estágios do ciclo de vida do produto. O primeiro tipo que chamamos de Sanity Review, e aconteceria antes que um desenvolvedor fizesse o teste de unidade - na verdade, o Sanity Reviews era feito antes mesmo de os recursos serem concluídos. A idéia era que um par de membros da equipe sentasse e repassasse algumas seções aleatórias de código, como no processo de desenvolvimento, para garantir que o desenvolvimento estivesse indo bem e que não teríamos um gigante. Entrada do TDWTF assim que o recurso estava pronto para ser incorporado. Isso foi feito principalmente para pessoas que precisavam de orientação extra (desenvolvedores juniores, novas contratações e pessoas designadas para trabalhar em algo com o qual estavam menos familiarizados do que outros membros da equipe), e geralmente era mantidos em uma reunião curta que abordava apenas problemas flagrantes.

Em seguida, tivemos análises de unidades. Isso geralmente era feito com três desenvolvedores e seria feito quando uma unidade / recurso era testado e estava pronto para ser mesclado na árvore principal. Esta foi a revisão mais abrangente e entraria em detalhes. Tínhamos três desenvolvedores para isso, porque tínhamos o autor original do código, o mantenedor da árvore que precisou assinar o código antes que ele pudesse ser incorporado e um terceiro desenvolvedor que foi selecionado para ser o backup do desenvolvedor original. (com a idéia de que uma vez que uma seção do código foi concluída, deveria haver uma transferência completa de conhecimento para outro membro da equipe, para que sempre houvesse pelo menos duas pessoas na equipe que estivessem totalmente à vontade com qualquer parte da base de código).

Por fim, tivemos análises de projetos. Isso abrangeu toda a equipe e levaria cerca de uma semana, e foi feito após o controle de qualidade e o lançamento do produto, e o objetivo era fazer com que todos participassem e passassem por todas as alterações em toda a base de código no último ciclo de lançamento, onde todos pudessem fale sobre mudanças arquitetônicas, dicas e decida o que precisava ser refatorado e corrigido antes de iniciarmos o desenvolvimento na próxima versão do projeto.

Primeiro, escreva testes automatizados para o código a ser desenvolvido. Revise os testes para garantir que todos os requisitos conhecidos estejam sendo testados. Escreva o código. Revise quantas vezes desejar.

Se qualquer teste manual for necessário, é essencial revisar o código antes de qualquer teste manual. Caso contrário, as melhorias de design sugeridas na revisão de código serão rejeitadas porque os testes manuais precisarão ser executados novamente.

Qual é o primeiro, o ovo ou a galinha?
Depende.

Se você é novo e não tem certeza do que faz, peça, por todos os meios, que um colega o ajude. Esta é uma revisão de código informal, mas muito séria e valiosa.

Geralmente, embora eu sugira que você faça seu próprio trabalho sujo primeiro, certifique-se de ter resolvido o código, comentado bem nos lugares certos (ou seja, os bits mais difíceis, não os óbvios), pelo menos basicamente funciona (você tem testados nos casos gerais mínimos e em alguns casos limites ou exceções). Então você leva para o seu colega.

A revisão antecipada do seu código pode resultar em um desperdício terrível do tempo de seus colegas. Revê-lo tarde demais pode resultar em um terrível desperdício de tempo. Você precisa encontrar o equilíbrio certo para obter a maior eficiência. Então, alguns testes vão primeiro, depois a revisão e mais testes. Potencialmente, você pode ter várias revisões de código, dependendo da complexidade e das iterações, com finalidades e focos diferentes.

Quanto menos você tiver mais avaliações (quando estiver na fase inicial de aprendizado, isso é normal). Quanto mais certeza você tiver, mais críticas também (nunca é bom ter muita certeza de si mesmo, o que significa que você geralmente não é tão bom como jogador de equipe e pode causar problemas a outras pessoas, você precisa garantir que seu código possa ser entendido e usado por outros). É quando você está no meio que as críticas podem ser espaçadas.

Apenas meus dois centavos.

A Capers-Jones, que estudou e mediu a eficiência e a qualidade resultantes dos processos de desenvolvimento de software mais do que qualquer outra pessoa, recomenda a seguinte sequência de atividades de remoção de defeitos:

• Inspeções de projeto
• Inspeções de código
• Testes unitários
• Novos testes de função
• Testes de regressão
• Testes de performance
• Testes do sistema
• Testes beta externos

Um dos motivos para realizar a inspeção do código antes do teste é que a revisão possa considerar não apenas o código em si, mas também a testabilidade do código.