Como escolho qual código revisar?

14

Eu faço parte de uma equipe de sete desenvolvedores em uma pequena empresa de software e estou tentando introduzir regularmente código de grupo e revisões de design. Realizamos algumas revisões no passado, mas tem sido esporádico. Eu gostaria de fazer uma coisa mais regular.

Eu li o Code Complete e outros recursos semelhantes e eles falam sobre a mecânica de como executar revisões de código, mas não consegui encontrar nenhuma prática recomendada sobre como escolher o que para revisar. Nós temos uma base de código que tem mais de oito anos e abrange uma variedade de idiomas, então há muitas coisas que podem ser analisadas.

Aqui estão alguns dos fatores que posso pensar que podem afetar a escolha:

  • Linguagem: C, Java, SQL, PL / SQL
  • Idade do código: código novo versus código antigo
  • Uso de código: código usado com frequência versus (efetivamente) código morto / pouco usado
  • Importância do código: código crítico versus código não crítico
  • Desenvolvedor: código de desenvolvedor júnior vs código de desenvolvedor sênior

Eu entendo que isso não é uma pergunta com uma resposta definitiva absoluta, mas qualquer orientação seria útil.

Algumas questões relacionadas à periferia:

por Burhan Ali 18.01.2012 / 19:01
fonte

5 respostas

12

Em geral, você precisa revisar tudo . Se uma nova aplicação tiver 2 000 LOC, todas as 2 000 LOC devem ser revistas.

É por isso que não há melhores práticas sobre como escolher o que analisar.

Se você abordar uma base de código grande existente, nunca revisada antes, então é a mesma coisa quando você deve reescrever uma base de código grande existente e escolher por onde começar. Depende strongmente:

  • na base de código (um único código monolítico seria mais difícil de reescrever / revisar que um conjunto de componentes separados, etc.),

  • seu contexto (você pode parar tudo em que trabalha e passar três meses (três anos?) trabalhando apenas em reescrever / revisar, ou você deve fazer isso por pequenos lapsos, somente quando tiver tempo livre)? / p>

  • o tipo de revisão que você faz (você tem uma lista de coisas para rever? Dependendo dos itens da lista de verificação, você pode querer rever algumas partes primeiro).

Se eu fosse você, gostaria de:

  • siga o princípio 80% -20%, mencionado no primeiro comentário da segunda pergunta que você vinculou.

  • considere que 100%, sendo ideal, talvez não valha a pena. É como 100% de cobertura de código para testes de unidade, exceto que essa cobertura de código é praticamente impossível ou extremamente cara.

  • comece com as partes do código que você mais usa e quais são as mais importantes. Se o codebase tiver uma biblioteca que autentique e registre novos usuários em seu site corporativo, revise-o primeiro, pois você certamente encontrará falhas de segurança antes que os hackers o façam.

  • use métricas existentes para determinar o que é mais importante analisar. Se uma parte da base de código não tiver nenhum teste de unidade, enquanto outra parte, igualmente importante, tiver 85% de cobertura de código, comece revisando a primeira parte. Se uma parte da base de código foi escrita por um desenvolvedor que era conhecido por ser inexperiente e apresentar mais bugs do que qualquer um de seus colegas, comece revisando seu código primeiro.

por 18.01.2012 / 19:10
fonte
4

Comece analisando todas as alterações feitas no código. Isso vai impedir que o problema piore. Em seguida, comece a revisar o código com base na frequência das alterações. estas serão as áreas de 'problema'.

Você precisará descobrir uma maneira de rastrear a revisão de uma seção de código para analisar a cobertura de revisão de seu código em relação a outras preocupações.

Se você puder determinar qual código não é coberto por seus testes, isso se tornará uma prioridade maior para revisão.

    
por 18.01.2012 / 19:37
fonte
3

Revise todas as novas alterações que foram feitas antes que elas cheguem à produção. scripts de instalação, código-fonte, alterações no banco de dados, tudo! O ponto principal da revisão de código é impedir que o código ruim seja transformado em produção. Seja um esquema organizacional ruim ou simplesmente um bug introduzido porque algo foi esquecido.

Refatorar o código atual no qual você está trabalhando anda de mãos dadas com a revisão de código. Por exemplo, quando estou revisando código, se havia código duplicado em uma classe que continha uma correção de bug, mesmo que o desenvolvedor não alterasse esse código em sua correção, eu não o passaria. Eu gostaria que eles voltassem e removessem o código duplicado.

Se você refatorar implacavelmente, a revisão de código se tornará útil. Caso contrário, é uma perda de tempo.

Se você incorporar o processo de revisão de código como etapa em seu processo de desenvolvimento, a base de código ficará melhor com o tempo. Melhor ainda, você não deve permitir que seus desenvolvedores assumam novos recursos ou consertos de bugs até que o backlog de revisão de código esteja vazio. Isso garante que a revisão do código seja feita.

Se houver áreas conhecidas que precisem ser refatoradas, levará muito tempo para executá-las (ou seja, 1 semana ou mais). Em seguida, crie um item de trabalho para essa refatoração e adicione-o como um item a ser trabalhado.

    
por 18.01.2012 / 21:36
fonte
2

Comece analisando todos os novos códigos e modificações no código existente.

Ao revisar modificações no código existente, o desenvolvedor deve seguir a regra do boyscout. Deixe o código melhor do que ele encontrou.

Isso não significa que você tenha que consertar o arquivo inteiro para ficar perfeito. Mas isso não deve aumentar a bagunça, deve ser um pouco melhor. Talvez movendo as modificações para novas classes que estão adequadamente estruturadas, e deixando o resto do arquivo de código original como está (afinal de contas, seu 'trabalho).

Depois de começar a melhorar o código, analisando todo o novo código e modificações, como desenvolvedores, você deve saber quais áreas do aplicativo exigem mais alterações. Em seguida, revise-as e discuta como elas podem ser melhoradas pouco a pouco.

Revisar o código escrito há 10 anos, por uma questão de revisão, é inútil, o desenvolvedor deve ter melhorado ao longo desses 10 anos. Então, não adianta revê-lo apenas para aprender o que todos sabem.

O objetivo das revisões de código é melhorar e corrigir os erros que você está cometendo atualmente e compartilhar esse conhecimento entre a equipe.

    
por 18.01.2012 / 19:43
fonte
1

No meu projeto, incluímos a revisão de código como um item obrigatório na maioria dos casos para qualquer tarefa / história do usuário / bug sendo desenvolvido. Estamos usando processos scrum / agile e ticket / story não é movido para o build (que é um backlog para QA) até que os testes unitários sejam escritos e a revisão do código seja concluída.

Utilizamos a análise Atlassian FishEye com a revisão de código do Crucible integrada com o JIRA + SVN para esse fim.

Quando o desenvolvedor verifica o código em busca de uma história específica, ele cria uma nova revisão de código no FishEye, onde ele seleciona os outros membros da equipe para fazer a revisão.

Após a revisão do código ser concluída (a ferramenta destaca as alterações enviadas e permite deixar os comentários para a linha de código específica), o desenvolvedor corrige os problemas mencionados / implementa as melhorias sugeridas e move o ticket para a coluna Construído no JIRA. significa que a história está pronta para ser testada e que não há mais alterações de código esperadas para este item de trabalho específico.

Isso também garante que o QA não teste nada que possa ser alterado e possivelmente seja quebrado durante a recriação do código após a revisão do código .

Para resumir, todo o código deve ser revisado - isso suporta a alta qualidade do código, que geralmente resulta em um melhor design, legibilidade, capacidade de manutenção e testabilidade do código e melhora o desempenho do desenvolvimento a longo prazo.

    
por 18.01.2012 / 23:18
fonte