Como escolho qual código revisar?

Faço parte de uma equipe de sete desenvolvedores em uma pequena empresa de software e estou tentando introduzir análises regulares de código e design de grupo. Realizamos algumas revisões no passado, mas elas foram esporádicas. Eu gostaria de fazer uma coisa mais regular.

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 as melhores práticas sobre como escolher o que revisar. Temos uma base de código com mais de oito anos e cobrindo uma variedade de idiomas; portanto, há muito que pode ser visto.

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

• Linguagem: C, Java, SQL, PL / SQL
• Idade do código: novo código vs código antigo
• Uso de código: código usado com frequência vs (efetivamente) código morto / pouco usado
• Importância do código: código crítico x código não crítico
• Desenvolvedor: Junior developer code vs Senior developer code

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

Algumas questões relacionadas à periferia:

• Abordagens de revisão de código (Menções de revisar seções críticas e novo código de desenvolvedor)
• Devemos tentar revisar todo o nosso código?

Em geral, você deve revisar tudo . Se um novo aplicativo tiver 2 000 LOC, todos os 2 000 LOC deverão ser revisados.

É por isso que não há práticas recomendadas sobre como escolher o que revisar.

Se você abordar uma base de código grande existente, nunca revisada antes, será a mesma coisa que você deve reescrever uma base de código grande existente e escolher por onde começar. Depende fortemente:

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

• seu contexto (você pode interromper tudo em que trabalha e passar três meses (três anos?) trabalhando apenas em reescrever / revisar ou deve fazê-lo em pequenos intervalos, apenas quando tiver tempo livre)?

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

Se eu fosse Você eu faria:

• siga o princípio de 80% a 20%, mencionado no primeiro comentário da segunda pergunta à qual você vinculou.

• leve em consideração que 100%, sendo um 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 é quase impossível ou extremamente cara.

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

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

Comece revendo todas as alterações feitas no código; isso vai parar o problema piorando. Em seguida, comece a revisar o código com base na frequência das alterações; estas serão as áreas 'problemáticas'.

Você vai querer descobrir uma maneira de rastrear que você revisou uma seção do código para poder analisar a cobertura de revisão do seu código em relação a outras preocupações.

Se você pode determinar qual código não é coberto por seus testes, isso se torna uma prioridade mais alta para revisão.

Revise todas as novas alterações que foram feitas antes de chegarem à 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 códigos incorretos entrem em produção. Seja um esquema organizacional ruim ou simplesmente um bug introduzido porque algo foi esquecido.

A refatoração do código atual em que você está trabalhando acompanha a revisão do código. Por exemplo, ao revisar o código, se houvesse código duplicado em uma classe que continha uma correção de bug, mesmo que o desenvolvedor não alterasse esse código na correção, eu não o passaria. Gostaria que eles voltassem e removessem o código duplicado.

Se você refatorar incansavelmente, a revisão do 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 do processo de desenvolvimento, a base de código ficará melhor com o tempo. Melhor ainda, você não deve permitir que seus desenvolvedores realizem trabalhos de novos recursos ou correções de bugs até que a lista de pendências de revisão de código esteja vazia. Isso garante que a revisão do código seja feita.

Se houver áreas conhecidas que precisam ser refatoradas, mas levará muito tempo para fazê-las (por exemplo, 1 semana ou mais). Em seguida, crie um item de trabalho para essa refatoração por si só e adicione-o como um item a ser trabalhado.

Comece revisando 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 escoteiro. Deixe o código melhor do que ele o encontrou.

Isso não significa que você precisa corrigir o arquivo inteiro para ser perfeito. Mas não deve aumentar a bagunça, deve torná-la um pouco melhor. Talvez movendo as modificações para novas classes que sejam adequadamente estruturadas e deixando o restante do arquivo de código original como está (afinal, está 'funcionando').

Depois de começar a melhorar o código revisando todos os novos códigos e modificações, como desenvolvedores, você deve saber quais áreas do aplicativo exigem mais alterações. Em seguida, revise-os, discuta como eles podem ser melhorados, pouco a pouco.

A revisão do código escrito há 10 anos, para fins de revisão, é inútil, o desenvolvedor deveria ter melhorado nesses 10 anos. Portanto, não faz sentido revisá-lo apenas para saber o que todos sabem.

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

No meu projeto, incluímos a revisão de código como um item obrigatório na maioria dos casos para qualquer atribuição / história do usuário / bug em desenvolvimento. Estamos usando processos scrum / ágeis e o ticket / história não é movido para a construção (que é um backlog para o controle de qualidade) até que os testes de unidade sejam gravados e a revisão do código seja concluída.

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

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

Após a conclusão da revisão do código (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 Built in JIRA - o que significa que a história é pronto para ser testado e que não há mais alterações de código esperadas para esse item de trabalho específico.

Isso também garante que o controle de qualidade não teste nada que possa ser alterado e potencialmente quebrado ao refatorar o código após a revisão .

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, manutenção e testabilidade do código e melhora o desempenho do desenvolvimento a longo prazo.