Todo mundo já passou por isso: você abre um pull request, o revisor aprova com um "LGTM" e, três semanas depois, um bug aparece justamente naquela linha que ninguém olhou duas vezes. Um code review checklist não resolve todos os problemas do mundo, mas tira a revisão do campo do improviso. Ele transforma a análise em um processo verificável, ponto por ponto, e garante que nenhuma área crítica fique de fora. Este checklist foi pensado para revisões de pull requests em times que usam Git, mas serve para qualquer revisão de código, mesmo aquela feita no papel, se ainda existir alguém nesse regime.
Use este checklist quando for revisar um pull request, antes de aprovar uma merge ou quando precisar avaliar a qualidade de um trecho de código que você não escreveu. Ele também é útil para quem está começando a revisar código e não sabe por onde começar. A ideia não é seguir a lista cegamente, mas usá-la como um guia para não esquecer o essencial.
1. Entendimento Geral do Contexto
Antes de olhar linha por linha, pergunte: o que este código faz e por que ele existe? Se a resposta não estiver clara no pull request, peça uma descrição melhor. Um código que não se explica sozinho já é um sinal de alerta.
2. Lógica e Fluxo de Dados
A lógica principal está correta? Siga o fluxo de dados de entrada até a saída, verificando se cada transformação faz sentido. Erros de lógica são os mais caros para corrigir depois, então vale a pena gastar tempo aqui.
3. Tratamento de Erros e Casos de Borda
O que acontece quando a entrada é vazia, nula, ou fora do intervalo esperado? Um bom código lida com o inesperado sem quebrar. Verifique se há tratamento para os casos mais prováveis e para os mais estranhos. Se o código falha, ele falha com uma mensagem útil ou com um silêncio misterioso?
4. Legibilidade e Clareza
Um código legível é um código que outro dev entende sem precisar de um seminário. Nomes de variáveis e funções descrevem o que fazem? A estrutura segue um fluxo lógico? Se você precisa de um comentário para explicar o que a linha faz, talvez a linha deva ser reescrita. Comentários são bem-vindos quando explicam o "porquê", não o "o quê".
5. Conformidade com Padrões do Time
Cada time tem suas convenções: indentação, nomenclatura, estrutura de pastas. O código segue essas regras? Se não, é uma oportunidade para alinhar o padrão ou questionar se ele precisa ser atualizado. Consistência importa mais do que gosto pessoal.
6. Testes Automatizados
Os testes unitários passam? E os testes de integração? Existe cobertura para os novos casos de borda que o código introduz? Um pull request sem testes é um convite para a regressão. Se o projeto não tem testes, este é o momento de começar a adicionar, pelo menos para o trecho novo.
7. Performance e Complexidade
O código é eficiente para o volume de dados que vai processar? Um loop aninhado pode ser inofensivo em um protótipo, mas fatal em produção. Avalie a complexidade algorítmica e o uso de recursos. Às vezes, uma solução mais simples e um pouco mais lenta é a escolha certa, mas isso precisa ser uma decisão consciente, não um acidente.
8. Segurança e Dados Sensíveis
O código expõe informações desnecessárias em logs ou respostas de API? Há validação de entrada para prevenir injeção de SQL ou XSS? Segurança não é um extra, é parte da revisão. Se você não se sente confortável para avaliar, peça ajuda a alguém com mais experiência na área.
9. Dependências e Compatibilidade
Novas bibliotecas foram adicionadas? Elas são necessárias e estão atualizadas? O código funciona com as versões atuais das dependências do projeto? Dependências desatualizadas são um risco de segurança e de compatibilidade. Se a mudança altera uma API pública, avalie o impacto nos consumidores.
10. Tratamento de Erros e Logs
Erros são capturados e registrados de forma útil? Um log que diz "algo deu errado" não ajuda ninguém. Verifique se as mensagens de erro são acionáveis e se os logs não contêm dados sensíveis. Um bom log é um aliado na investigação de incidentes.
11. Documentação e Comentários
A documentação do projeto foi atualizada se necessário? A docstring da função nova explica o que ela faz e como usá-la? Comentários confusos ou desatualizados são piores do que nenhum comentário. Se o código muda e o comentário fica para trás, o próximo leitor vai confiar em qual deles?
12. Escopo da Mudança
O pull request faz uma coisa só ou tenta resolver três problemas de uma vez? Mudanças pequenas e focadas são mais fáceis de revisar e de reverter se algo der errado. Se o escopo cresceu, sugira dividir em pull requests menores. Revisar 500 linhas de uma vez é um convite para erros.
13. Compatibilidade com Outras Partes do Sistema
O código novo quebra alguma funcionalidade existente? Ele é compatível com a versão anterior da API ou do banco de dados? Verifique chamadas a funções que mudaram de assinatura e renomeações de campos. Uma mudança que parece local pode ter efeitos colaterais em módulos distantes.
14. Revisão de Nomes e Convenções
Os nomes escolhidos são claros e seguem o padrão do projeto? Uma função chamada processData pode significar qualquer coisa. validateAndNormalizeInput é mais específico e autoexplicativo. Nomes bons reduzem a necessidade de comentários e facilitam a busca no código.
15. Decisão de Aprovação
Depois de passar pelos pontos anteriores, a pergunta final: esta mudança está pronta para ir para produção? Se houver dúvidas, não aprove. Prefira pedir ajustes a liberar um risco conhecido. Aprovar por pressão ou para "não atrasar o deploy" é o erro mais comum que um revisor pode cometer. A revisão é a última barreira antes do bug chegar ao usuário.
O Erro Mais Comum: Revisar sem Critério
O erro mais comum em code review não é esquecer um item específico, é revisar sem um critério definido. Quem olha o código sem uma lista mental ou escrita tende a focar no que é mais visível, como estilo de formatação, e ignorar o que importa de verdade, como lógica e segurança. O resultado é um falso senso de segurança: o pull request foi "aprovado", mas ninguém verificou se o fluxo de erro funciona ou se os dados sensíveis estão protegidos.
Um checklist não elimina a necessidade de atenção, mas organiza a atenção. Ele garante que você olhe para cada área crítica, mesmo que rapidamente. Com o tempo, os pontos viram hábito e a revisão fica mais rápida e mais confiável. Até o dia em que você encontra um bug que passou por três revisões. Aí você volta ao checklist e descobre que ninguém marcou a caixa de casos de borda. Acontece com os melhores.
Perguntas Frequentes sobre Code Review Checklist
O que é um code review checklist?
Um code review checklist é uma lista de verificação com pontos específicos para avaliar durante a revisão de código. Ele cobre áreas como lógica, segurança, performance, legibilidade e testes. O objetivo é garantir que a revisão seja consistente e que nenhum aspecto crítico seja esquecido.
Como criar um code review checklist para o meu time?
Comece com uma lista básica como esta e adapte à realidade do seu projeto. Inclua pontos específicos do seu domínio, como regras de negócio ou conformidade. Revise a lista periodicamente com o time para ajustar o que não funciona.
Qual a diferença entre code review e code review checklist?
Code review é o processo de analisar código escrito por outra pessoa. O checklist é uma ferramenta que estrutura esse processo, listando pontos a verificar. O checklist não substitui a revisão, apenas a organiza.
Com que frequência devo usar o checklist?
Use em toda revisão de pull request, pelo menos até os pontos se tornarem hábito. Depois, pode ser usado como referência para revisões mais complexas ou quando o time está sob pressão. A consistência é mais importante do que a frequência.
O checklist serve para qualquer linguagem de programação?
Sim, a maioria dos pontos é genérica e se aplica a qualquer linguagem. Aspectos específicos, como segurança de memória em C ou gerenciamento de pacotes em Python, podem ser adicionados conforme a necessidade. O núcleo, que inclui lógica, legibilidade e testes, é universal.
Como lidar com um revisor que não segue o checklist?
Converse com a pessoa e explique o objetivo do checklist. Ofereça-se para revisar juntos um pull request e mostrar como o checklist ajuda a encontrar problemas. Se a resistência continuar, talvez valha a pena revisar o checklist para torná-lo mais enxuto e aplicável. O objetivo é facilitar o trabalho, não criar burocracia.
Agora que você tem o checklist, imprima, cole perto do monitor ou salve em um arquivo. Na próxima revisão, marque cada item e veja a diferença. O código agradece, o time agradece e, principalmente, o seu eu do futuro, que não vai precisar depurar um bug às 23h, agradece. Tudo digital, menos a paciência.