Faça comentários curtos.
É difícil manter a concentração, especialmente durante a revisão do código, por um longo tempo. Além disso, revisões longas de código podem indicar que há muito a dizer sobre o código (veja os próximos dois pontos) ou que a revisão se torna uma discussão sobre questões maiores, como a arquitetura.
Além disso, uma revisão deve permanecer uma revisão, não uma discussão. Isso não significa que o autor do código não possa responder, mas não deve se transformar em uma longa troca de opiniões.
Evite revisar o código que é muito ruim.
A revisão do código de baixa qualidade é deprimente para o revisor e o autor do código. Se um pedaço de código é terrível, uma revisão de código não é útil. Em vez disso, o autor deve ser solicitado a reescrever o código corretamente.
Use verificadores automatizados antes da revisão.
Damas automáticas evitam desperdiçar um tempo precioso apontando erros que podem ser encontrados automaticamente. Por exemplo, para código C #, a execução de StyleCop, métricas de código e especialmente análise de código é uma boa oportunidade para encontrar alguns dos erros anteriores à revisão. Em seguida, a revisão de código pode ser gasta em pontos extremamente difíceis de fazer para uma máquina.
Escolha com cuidado as pessoas que fazem revisões.
Duas pessoas que não conseguem se suportar não farão uma boa revisão do código da outra. O mesmo problema surge quando uma pessoa não respeita a outra (a propósito, seja o revisor ou o autor).
Além disso, algumas pessoas simplesmente não conseguem ver seu código revisado; portanto, precisam de treinamento e preparação específicos para entender que não são criticados e que não devem vê-lo como algo negativo. Fazer uma revisão, despreparado, não ajudará, pois estará sempre na defensiva e não ouvirá nenhum crítico de seu código (tomando todas as sugestões como críticas).
Faça análises informais e formais.
Ter uma lista de verificação ajuda a concentrar-se em um conjunto preciso de falhas, evitando se dedicar à seleção de itens. Esta lista de verificação pode conter pontos como:
- Injeção SQL,
- Pressupostos errados sobre um idioma que pode levar a erros,
- Situações específicas que podem levar a erros, como precedência do operador. Por exemplo, em C #,
var a = b ?? 0 + c ?? 0;pode parecer bom para alguém que deseja adicionar dois números anuláveis com coalescência em zero, mas não é.
- Desalocação de memória,
- Carregamento lento (com seus dois riscos: carregar a mesma coisa mais de uma vez e sem carregá-la),
- Estouros,
- Estruturas de dados (com erros como uma lista simples em vez de um conjunto de hash, por exemplo),
- Validação de entrada e programação defensiva em geral,
- Segurança da linha,
- etc.
Paro a lista aqui, mas existem centenas de pontos que podem aparecer em uma lista de verificação, dependendo dos pontos fracos de um autor preciso.
Ajuste progressivamente a lista de verificação.
Para permanecer construtivo e útil ao longo do tempo, as listas de verificação usadas nas revisões formais devem ser ajustadas ao longo do tempo, dependendo dos erros encontrados. Por exemplo, as primeiras revisões informais podem revelar uma certa quantidade de riscos da injeção de SQL. A verificação de injeção SQL será incluída na lista de verificação. Quando, alguns meses depois, parece que o autor agora tem muito cuidado com consultas dinâmicas versus parametrizadas, a injeção de SQL pode ser removida da lista de verificação.