Quais são algumas das melhores práticas para a revisão de códigos?

SmartBear Software company published a small white-paper with 11 good practices for an effective code review process:

1. Review less than 200-400 lines of code (LOC) at a time: Mais de 400 LOC exigirão mais tempo, e desmoralizarão o revisor, que saberá antes de tudo que esta tarefa lhe levará muito tempo.
2. li>Avisar para uma taxa de inspeção de menos de 300-500 LOC/hora: É preferível rever menos LOC mas procurar situações como bugs, possíveis falhas de segurança, possíveis falhas de optimização e até possíveis falhas de design ou arquitectura.
3. li>Tem tempo suficiente para uma revisão adequada e lenta, mas não mais do que 60-90 minutos: Como é uma tarefa que requer atenção aos detalhes, a capacidade de concentração irá diminuir drasticamente quanto mais tempo a tarefa demorar a ser concluída. Por experiência pessoal, após 60 minutos de revisão efetiva do código, ou você faz uma pausa (vai tomar um café, levanta-se da cadeira e faz alguns alongamentos, lê um artigo, etc.), ou você começa a ser complacente com o código em assuntos sensíveis como questões de segurança, otimização e escalabilidade.li>li>Authors devem anotar o código fonte antes do início da revisão: É importante que o autor informe aos colegas quais arquivos devem ser revisados, evitando que códigos previamente revisados sejam novamente validados.
4. Estabelecer metas quantificáveis para a revisão do código e capturar métricas para que você possa melhorar seus processos: é importante que a equipe de gerenciamento tenha uma maneira de quantificar se o processo de revisão do código é eficaz, como a contabilização do número de bugs reportados pelo cliente.
5. Listas de verificação melhoram substancialmente os resultados tanto para os autores quanto para o revisor: O que rever? Sem uma lista, cada engenheiro pode procurar por algo em particular e deixar esquecido outros pontos importantes.
6. Verifiquem se os defeitos são realmente corrigidos! Não basta que um revisor indique onde estão as falhas ou sugira melhorias. E não é uma questão de confiar nos colegas. É importante validar que, de fato, as mudanças onde bem implementadas.
7. os gerentes devem fomentar uma boa cultura de revisão de código na qual a descoberta de defeitos seja vista positivamente. É necessário evitar a cultura de "por que você não a escreveu bem na primeira vez". É importante que zero bugs sejam encontrados na produção. A fase de desenvolvimento e revisão é onde eles devem ser encontrados. É importante ter espaço para que um engenheiro cometa um erro. Só então você pode aprender algo novo.
8. Beware o efeito "Big Brother": Semelhante ao ponto 8, mas do ponto de vista do engenheiro. É importante estar ciente de que as sugestões ou bugs relatados nas revisões de código são quantificáveis. Estes dados devem servir aos gestores para ver se o processo está a funcionar ou se um engenheiro está com dificuldades particulares. Mas nunca devem ser usados para avaliações de performance.
9. O Efeito Ego: Faça pelo menos alguma revisão de código, mesmo que você não tenha tempo para revisar tudo: Sabendo que nosso código será revisto por pares nos alerta para sermos mais cautelosos no que escrevemos.
10. As revisões de código de estilo leve são eficientes, práticas e eficazes para encontrar bugs: Não é necessário entrar no procedimento descrito pela IBM há 30 anos, onde 5-10 pessoas se fechariam para reuniões periódicas com impressões de código e rabiscos em cada linha de código. Usando ferramentas como Git, você pode participar do processo de revisão de código, escrever e associar comentários com linhas específicas, discutir soluções através de mensagens assíncronas com o autor, etc.

Aconselho a leitura do documento para uma visão mais profunda de cada ponto.

É impossível refutar que a revisão de código irá melhorar a qualidade do código produzido, reduzindo o número de bugs e melhorando o design. Existem alguns recursos adicionais, como compartilhar conhecimento entre colegas e orientar mais membros da equipe júnior.

É um fato que este processo, mesmo que feito de uma forma mais leve, levará tempo para o projeto. No processo de revisão, temos que adicionar o tempo de resposta do autor e novamente o tempo de revisão novamente. Numa tentativa de agilizar esse consumo de tempo, aconselho que, após duas revisões sem sucesso, o autor e o revisor se sentem lado a lado e debatam a peça de código que está causando o problema.

Mas é realmente importante dizer uma frase do site da IBM - Slow down para ir mais rápido.

Eu gostaria de terminar com uma nota, que eu tenho como muito importante. O processo de revisão de código exige que toda a equipe de desenvolvimento demonstre alta inteligência emocional. Como regra, os programadores têm um ego forte e sentem que são "pais" do código escrito por eles mesmos. Às vezes não é fácil aceitar comentários menos construtivos. Comentários totalmente destrutivos, provocadores ou jocosos "farão mais mal do que bem", e podem até destruir a moral de uma equipe. É importante seguir estes elementos, para tentar mudar suas atitudes ou, como último recurso, removê-los da equipe.