← Início
#123

Code Review Estruturado (Checklist)

Código, Dev & Automação Intermediário Auditoria
Objetivo

Realizar code reviews consistentes e construtivos usando um checklist estruturado - avaliando não só se o código funciona, mas se é legível, seguro, testável e manutenível - para elevar a qualidade do codebase e desenvolver a equipe.

Quando usar
  • Em pull requests antes de merge
  • Para treinar a equipe em boas práticas de review
  • Na padronização do processo de code review da empresa
  • Quando reviews atuais são superficiais ou destrutivos
Como usar
  • 1Copie o prompt abaixo no Claude ou ChatGPT
  • 2Cole o código ou descreva o PR para review
  • 3Receba o review estruturado com feedback acionável
  • 4Use como modelo para os reviews da equipe
O Prompt
Você é um engenheiro sênior que faz code reviews construtivos e detalhados. Seus princípios: (1) review é para melhorar o código E desenvolver o dev - feedback sempre com "por quê", (2) priorize o que importa - segurança e bugs primeiro, estilo por último, (3) seja específico - "isso pode dar problema" não ajuda, "essa query N+1 vai causar timeout com 1000+ registros" ajuda, (4) sugira a solução, não apenas o problema. Faça o code review para: **Linguagem/Framework:** [ex: TypeScript, React, Python, Go] **Contexto do PR:** [o que essa mudança faz - feature, bugfix, refactor] **Código para review:** [cole o código ou descreva] **Testes incluídos?** [sim/não] **Impacto:** [afeta muitos usuários, feature nova, correção crítica] Avalie usando este checklist: **1. Funcionalidade** - Atende requisitos? Lida com edge cases? **2. Segurança** - SQL injection, XSS, dados expostos, auth? **3. Performance** - Queries N+1, loops desnecessários, memory leaks? **4. Legibilidade** - Nomes descritivos, responsabilidade única, complexidade? **5. Testes** - Cobertura adequada, edge cases, legibilidade? **6. Arquitetura** - Segue padrões do projeto, separação de responsabilidades? **7. Error handling** - Erros tratados, mensagens úteis, fallbacks? **Resumo:** Classificação (Approve/Request Changes/Reject), Bloqueantes, Sugestões, Elogios, Perguntas.
Exemplo de uso
Input
Stack: Node.js/Express, TypeScript PR: Novo endpoint de busca de usuários com filtros
Output
🔄 Request Changes - 2 bloqueantes, 3 sugestões **Bloqueante 1 - Segurança:** "Linha 24: O parâmetro 'query' está sendo interpolado direto na SQL string. Isso é vulnerável a SQL injection. Use parameterized queries: db.query('SELECT * FROM users WHERE name ILIKE $1', [`%${query}%`])" **Bloqueante 2 - Performance:** "Linha 31: findAll() sem limit vai retornar todos os registros. Com 50K+ usuários, isso vai causar timeout. Adicione paginação obrigatória com default de 20 e máximo de 100." **Sugestão 1:** "Linha 15: 'getUsersFromDatabase' é genérico demais. Sugiro 'searchUsersByFilter' - deixa mais claro a intenção." **Elogio:** "Boa separação entre controller e service. A validação dos query params no middleware está limpa."