Checklist code review: 12 itens para revisar antes

Revisar código é parte do dia a dia de qualquer time que preza por qualidade. Mas quem pede a revisão também tem responsabilidade: entregar um código que respeite o tempo de quem vai avaliar. Um checklist code review bem aplicado transforma a revisão em um processo mais rápido, objetivo e menos desgastante.

Este checklist serve para o momento antes de abrir o pull request. Use-o como filtro final: se você consegue marcar cada item, seu código está pronto para ser revisado. Se não, ajuste antes de pedir a revisão.

Testes: o que precisa passar antes de pedir revisão

Nada atrasa mais uma revisão do que um código com teste quebrado. O revisor precisa confiar que a base está estável para se concentrar em lógica e arquitetura.

• Suíte de testes local passa: rode os testes do módulo alterado e os testes de regressão. Não espere o CI apontar uma falha que você poderia ter visto localmente.
• Testes cobrem o novo comportamento: se você adicionou uma função, existe um teste que valida o caso feliz e pelo menos um caso de erro ou borda.
• Casos de borda cobertos: entrada vazia, valor nulo, limite máximo, formato inesperado. O revisor vai procurar exatamente esses pontos.
• Nenhum teste comentado ou ignorado: código comentado gera dúvida. Se um teste não faz mais sentido, remova-o em vez de deixá-lo desativado.

Legibilidade: o código precisa ser claro para outra pessoa

O revisor não conhece o contexto interno da sua cabeça. Ele lê o código como se fosse a primeira vez. Por isso, clareza vale mais que esperteza.

• Nomes de variáveis e funções descritivos: calcularTotalComDesconto é melhor que calcTot. Nomes revelam intenção.
• Funções com responsabilidade única: se uma função faz mais de uma coisa, divida. Funções pequenas são mais fáceis de testar e revisar.
• Comentários explicam o porquê, não o quê: um comentário que repete o código é ruído. Explique decisões não óbvias, como uma escolha de algoritmo ou um workaround.
• Sem código morto: variáveis não usadas, imports sem utilidade, funções que não são chamadas. Isso polui a leitura e gera perguntas desnecessárias.

Performance: sem surpresas para quem vai operar

Performance não é sobre otimizar tudo. É sobre não introduzir problemas óbvios que vão custar caro depois.

• Complexidade adequada ao tamanho dos dados: um loop aninhado pode ser aceitável para 100 itens e inviável para 1 milhão. Avalie o contexto real de uso.
• Sem consultas N+1: se o código acessa um banco de dados, verifique se não há consultas repetidas dentro de loops. Uma consulta com JOIN pode resolver.
• Recursos são liberados: conexões de banco, arquivos abertos e streams precisam ser fechados. Use try-with-resources ou o equivalente na sua linguagem.
• Sem trabalho repetido: cálculos que podem ser feitos uma vez fora do loop, ou valores que podem ser cacheados, evitam desperdício de CPU e memória.

Boas práticas: consistência com o que já existe no projeto

Cada projeto tem suas convenções. Seguí-las mostra que você entende o contexto e facilita a vida de quem mantém o código.

• Estilo segue o padrão do projeto: formatação, indentação, aspas simples ou duplas. Se o projeto usa um formatter automático, rode antes de submeter.
• Tratamento de erros consistente: use o mesmo padrão de exceções ou retorno de erros do restante do código. Misturar estilos confunde o revisor.
• Sem mudanças não relacionadas: o pull request deve ter um escopo único. Correção de espaçamento em um arquivo não relacionado tira o foco da revisão.
• Dependências novas justificadas: se você adicionou uma biblioteca, explique no pull request por que ela é necessária. Dependência nova é decisão de time, não individual.

Documentação e contexto: o revisor precisa entender o motivo

Um pull request sem contexto é um convite a perguntas. O revisor quer saber o que mudou e por quê.

• Descrição do pull request com objetivo claro: explique o problema que o código resolve e como ele resolve. Não precisa ser longo, mas precisa ser específico.
• Link para issue ou ticket: se existe uma tarefa associada, referencie. Isso dá histórico e permite ao revisor buscar mais contexto.
• Mudanças de comportamento documentadas: se a alteração muda uma API, um contrato ou um comportamento de usuário, registre isso. Quem usa o sistema precisa saber.
• Screenshots ou exemplos de saída: para mudanças visuais ou de fluxo, uma captura de tela vale mais que mil palavras de descrição.

O erro mais comum: revisar o código no lugar de revisar o autor

O erro mais comum em code review não é técnico. É pessoal: quem submete o código trata comentários como crítica pessoal, e quem revisa trata o autor como culpado. Isso transforma a revisão em disputa, não em colaboração.

Lembre-se de que o objetivo do checklist não é provar que você é bom. É garantir que o código entregue seja sólido, legível e sustentável. Quando o autor prepara o código com cuidado e o revisor comenta com respeito, a revisão fica mais rápida e o time aprende junto.

Aplicar este checklist antes de cada pull request reduz o ciclo de revisão, diminui idas e vindas e protege o tempo de todo mundo.

Perguntas frequentes sobre checklist code review

O que deve conter um checklist de code review?

Um checklist de code review deve conter itens verificáveis sobre testes, legibilidade, performance, boas práticas e documentação. O foco é garantir que o código está pronto para revisão antes de o pull request ser aberto, reduzindo retrabalho e comentários repetitivos.

Quem deve usar o checklist de code review?

O autor do código deve usar o checklist antes de submeter a alteração. O revisor também pode usá-lo como guia para garantir que nenhum aspecto importante foi esquecido. Times que adotam o checklist relatam revisões mais rápidas e menos ruído.

Qual a diferença entre checklist e padrão de codificação?

Padrão de codificação define regras fixas, como nomenclatura e formatação. O checklist é mais amplo: inclui testes, performance e contexto do pull request. O checklist complementa o padrão, mas não o substitui.

Como criar um checklist para meu time?

Comece com itens genéricos deste artigo e adapte à realidade do projeto. Inclua particularidades da stack, como padrões de banco ou de API. Revise o checklist periodicamente para remover itens obsoletos e adicionar novos aprendizados.

O checklist deve ser seguido à risca?

O checklist é um guia, não uma camisa de força. Itens podem ser adaptados conforme o contexto. O importante é que ele traga consistência e evite que pontos críticos passem despercebidos na pressa do dia a dia.