Code Review Patterns

Quando Usar

Ativar quando:

• Código novo foi implementado
• Pull request precisa de review
• Refatoração foi feita

Checklist de Review

1. Funcionalidade

• Código faz o que deveria fazer
• Edge cases tratados
• Comportamento consistente

2. Qualidade

• Código legível e bem organizado
• Nomes descritivos (variáveis, funções, classes)
• Funções pequenas e focadas (< 50 linhas ideal)
• Sem código duplicado (DRY)
• Sem código morto/comentado

3. Segurança

• Sem credenciais hardcoded
• Input validation presente
• Sem SQL injection
• Sem XSS vulnerabilities
• Dados sensíveis protegidos
• Logs não expõem dados sensíveis

4. Performance

• Sem N+1 queries
• Algoritmos eficientes
• Recursos liberados corretamente
• Caching onde apropriado

5. Tratamento de Erros

• Erros capturados adequadamente
• Mensagens de erro úteis
• Fallbacks implementados
• Logging de erros

6. Testes

• Testes existem para nova funcionalidade
• Testes passando
• Cobertura adequada (> 80% ideal)
• Testes são legíveis

7. Documentação

• Funções públicas documentadas
• Complexidade explicada
• README atualizado se necessário

Formato de Report

## Code Review: [descrição]

### Sumário
- **Arquivos:** X modificados
- **Linhas:** +Y / -Z
- **Issues:** A críticos, B médios, C baixos

### Issues Encontrados

#### Críticos (bloqueia merge)
1. **[arquivo:linha]** Descrição
   - Problema: ...
   - Solução: ...

#### Médios (deveria corrigir)
2. **[arquivo:linha]** Descrição

#### Baixos (nice to have)
3. **[arquivo:linha]** Descrição

### Pontos Positivos
- Boa separação de responsabilidades
- Testes bem escritos

### Recomendações
1. ...
2. ...

### Veredicto
- [ ] Aprovado
- [ ] Aprovado com ressalvas
- [ ] Precisa de correções

Severidade de Issues

Crítico

• Bugs que quebram funcionalidade
• Vulnerabilidades de segurança
• Perda de dados possível
• Ação: Bloqueia merge

Médio

• Code smells
• Performance issues
• Falta de testes
• Ação: Deveria corrigir

Baixo

• Estilo/formatação
• Melhorias opcionais
• Documentação
• Ação: Nice to have

Boas Práticas de Review

DO

• Seja específico e construtivo
• Sugira soluções, não só problemas
• Reconheça código bem escrito
• Foque no código, não na pessoa

DON'T

• Críticas pessoais
• Nitpicking excessivo
• Bloquear por preferência pessoal
• Ignorar contexto/deadline