Code Review - Revisão Sistemática de Código

Esta skill implementa um processo sistemático de code review para garantir qualidade, segurança e manutenibilidade do código.

Princípios do Code Review

O objetivo não é encontrar erros, é melhorar o código e compartilhar conhecimento.

Mentalidade Correta

Processo de Review (5 Fases)

Fase 1: Contexto (2 min)

┌─────────────────────────────────────────┐
│  1. Leia a descrição do PR/MR           │
│  2. Entenda o objetivo da mudança       │
│  3. Verifique issues relacionadas       │
│  4. Revise o escopo das mudanças        │
└─────────────────────────────────────────┘

Perguntas:

• •O que este PR resolve?
• •Qual o impacto esperado?
• •Há breaking changes?

Fase 2: Visão Geral (5 min)

┌─────────────────────────────────────────┐
│  1. Revise a lista de arquivos mudados  │
│  2. Identifique padrões nas mudanças    │
│  3. Note arquivos críticos (auth, db)   │
│  4. Verifique tamanho do diff           │
└─────────────────────────────────────────┘

Red Flags:

• • PR muito grande (>500 linhas) - pedir para dividir
• • Mudanças em arquivos não relacionados
• • Arquivos sensíveis modificados (auth, security)

Fase 3: Análise Detalhada (15-30 min)

┌─────────────────────────────────────────┐
│  1. Revise cada arquivo metodicamente   │
│  2. Verifique lógica e edge cases       │
│  3. Analise tratamento de erros         │
│  4. Confirme cobertura de testes        │
└─────────────────────────────────────────┘

Fase 4: Testes e Validação (5 min)

┌─────────────────────────────────────────┐
│  1. Testes unitários existem?           │
│  2. Testes cobrem casos importantes?    │
│  3. CI/CD passou?                       │
│  4. Testes manuais necessários?         │
└─────────────────────────────────────────┘

Fase 5: Feedback (5 min)

┌─────────────────────────────────────────┐
│  1. Organize comentários por prioridade │
│  2. Sugira melhorias específicas        │
│  3. Reconheça código bem escrito        │
│  4. Dê veredicto claro                  │
└─────────────────────────────────────────┘

Checklist de Review

Funcionalidade

• • O código faz o que deveria?
• • Edge cases são tratados?
• • Erros são capturados e tratados?
• • Não há regressões óbvias?

Código Limpo

• • Nomes de variáveis são descritivos?
• • Funções são pequenas e focadas?
• • Não há código duplicado?
• • Comentários são necessários e úteis?

Segurança

• • Inputs são validados?
• • Não há SQL injection?
• • Não há XSS?
• • Secrets não estão hardcoded?
• • Auth/authz são verificados?

Performance

• • Queries são eficientes?
• • Não há N+1 queries?
• • Loops são otimizados?
• • Caching é usado onde apropriado?

Testes

• • Testes unitários existem?
• • Testes cobrem happy path?
• • Testes cobrem error cases?
• • Testes são legíveis?

Manutenibilidade

• • Código segue padrões do projeto?
• • TypeScript types estão corretos?
• • Imports estão organizados?
• • Não há TODOs sem tracking?

Níveis de Severidade

🔴 Blocker (Deve Corrigir)

• •Bugs que quebram funcionalidade
• •Vulnerabilidades de segurança
• •Vazamento de dados/secrets
• •Performance crítica

Template:

🔴 **BLOCKER**: [Descrição]

**Problema:** [O que está errado]
**Impacto:** [Consequência]
**Sugestão:** [Como corrigir]

🟡 Warning (Deveria Corrigir)

• •Code smells
• •Falta de tratamento de erro
• •Testes insuficientes
• •Documentação faltando

Template:

🟡 **WARNING**: [Descrição]

**Problema:** [O que poderia melhorar]
**Sugestão:** [Melhoria proposta]

🟢 Suggestion (Nice to Have)

• •Melhorias de estilo
• •Refatorações opcionais
• •Otimizações menores

Template:

🟢 **SUGGESTION**: [Descrição]

**Ideia:** [Sugestão de melhoria]

💬 Question (Pedido de Clarificação)

• •Não entendi a lógica
• •Preciso de contexto
• •Decisão de design

Template:

💬 **QUESTION**: [Pergunta]

**Contexto:** [Por que está perguntando]

👍 Praise (Reconhecimento)

• •Código bem escrito
• •Boa solução
• •Melhoria notável

Template:

👍 **NICE**: [O que gostou]

Padrões de Comentário

Bom Comentário

🟡 **WARNING**: Possível race condition

**Linha 45:** A verificação `if (user)` e a atualização `user.update()`
não são atômicas. Em alta concorrência, outro request pode modificar
o user entre essas operações.

**Sugestão:** Use uma transação ou lock otimista:
\`\`\`typescript
await db.transaction(async (tx) => {
  const user = await tx.user.findUnique({ where: { id } });
  if (user) await tx.user.update({ where: { id }, data });
});
\`\`\`

Comentário Ruim

❌ "Isso está errado"
❌ "Não gosto desse código"
❌ "Por que você fez isso?"

Veredictos

✅ Approve

"Código revisado e aprovado. Ótimo trabalho no [aspecto específico]!"

Usar quando:

• •Não há blockers
• •Warnings são menores
• •Testes passam

🔄 Request Changes

"Há alguns pontos que precisam de ajuste antes do merge. Veja os comentários marcados como BLOCKER."

Usar quando:

• •Há blockers de segurança
• •Bugs críticos encontrados
• •Testes falhando

💬 Comment

"Deixei algumas sugestões e perguntas. Nada bloqueante, mas gostaria de discutir antes de aprovar."

Usar quando:

• •Precisa de clarificação
• •Mudanças de design questionáveis
• •Quer discussão antes de decidir

Template de Review Completo

## Code Review: [Título do PR]

### Resumo
[1-2 frases sobre o que foi revisado]

### Pontos Positivos
- 👍 [Aspecto bem feito]
- 👍 [Outro aspecto]

### Issues Encontradas

#### Blockers (🔴)
1. [Issue 1]
2. [Issue 2]

#### Warnings (🟡)
1. [Warning 1]
2. [Warning 2]

#### Suggestions (🟢)
1. [Suggestion 1]

### Perguntas
1. 💬 [Pergunta sobre decisão de design]

### Veredicto
[✅ Approve | 🔄 Request Changes | 💬 Comment]

### Próximos Passos
- [ ] [Ação necessária]

Anti-Patterns de Review

Esta skill ativa AUTOMATICAMENTE quando:

• •Usuário menciona "code review" ou "PR review"
• •Discussão sobre merge/pull requests
• •Pedido para revisar código
• •Análise de qualidade de código