Modulo 5.6 - Skill: Senior Code Review | 6 Pilares do Claude Code Resumido

🔒 Analise de Seguranca

O primeiro passe do Senior Code Review foca em vulnerabilidades de seguranca. E a analise mais critica porque bugs de seguranca podem comprometer todo o sistema, nao apenas uma feature.

🎯 Conceito Principal

•Injection: SQL injection, XSS, command injection, path traversal
•Auth: Broken authentication, missing authorization checks, IDOR
•Data: Secrets hardcoded, PII exposure, insecure storage
•Deps: Dependencias com CVEs conhecidos, versoes desatualizadas

💡 Dica Pratica

Inclua na skill: "Se encontrar secrets hardcoded (API keys, passwords, tokens), marque como CRITICAL e sugira usar environment variables. Nunca inclua o valor do secret no relatorio." Isso previne que o proprio relatorio de review se torne um vazamento.

🐛 Deteccao de Bugs

O segundo passe busca bugs logicos, edge cases nao tratados e erros potenciais que podem causar crashes ou comportamento inesperado em producao.

🎯 Conceito Principal

•Null/undefined: Acessos sem null check, optional chaining ausente
•Race conditions: Acesso concorrente sem sincronizacao
•Error handling: Try/catch vazios, erros silenciados, promises sem .catch
•Edge cases: Lista vazia, string vazia, numeros negativos, overflow

💡 Dica Pratica

Peca ao Claude para simular mentalmente a execucao do codigo com inputs extremos: lista de 1 milhao de itens, string de 10MB, requisicao com timeout de 1ms. Isso forca a deteccao de edge cases que ninguem pensou durante o desenvolvimento.

⚡ Analise de Performance

O terceiro passe identifica gargalos de performance, complexidade desnecessaria e oportunidades de otimizacao que podem impactar a experiencia do usuario e os custos de infraestrutura.

🎯 Conceito Principal

•Complexidade: O(n²) onde O(n) e possivel, nested loops desnecessarios
•N+1 queries: Loop que faz query individual em vez de batch
•Memory leaks: Event listeners nao removidos, closures retendo referencias
•Caching: Computacoes repetidas que poderiam ser cacheadas

💡 Dica Pratica

Adicione na skill: "So reporte issues de performance que tenham impacto mensuravel. Nao sugira micro-otimizacoes prematures. Foque em N+1 queries, complexidade algoritmica e memory leaks." Isso evita relatorios cheios de sugestoes inuteis tipo "use const em vez de let".

📐 Qualidade de Codigo

O quarto passe avalia legibilidade, manutencao e aderencia a padroes. Codigo que funciona mas e impossivel de manter e uma divida tecnica que cresce exponencialmente.

🎯 Conceito Principal

•Naming: Variaveis e funcoes com nomes descritivos e consistentes
•DRY: Codigo duplicado que deveria ser extraido em funcao
•SRP: Funcoes fazendo muitas coisas, classes com responsabilidades misturadas
•Types: TypeScript com any, tipos genericos demais, interfaces ausentes

💡 Dica Pratica

Adapte os padroes de qualidade para o projeto: "Seguir os padroes definidos no CLAUDE.md do projeto. Se nao existir, usar as convencoes ja presentes no codebase." Isso evita que o review sugira padroes que conflitam com o estilo do time.

📊 Formato de Saida

O relatorio final e estruturado em secoes claras com score numerico, findings categorizados e acoes recomendadas. Formato padrao que o time inteiro aprende a ler e agir rapidamente.

🎯 Conceito Principal

# Output Format

## Code Review: [file/PR name]
**Overall Score**: X/10
**Verdict**: APPROVE / REQUEST CHANGES / NEEDS DISCUSSION

### 🔒 Security (X issues)
| Severity | Location | Issue | Fix |
|----------|----------|-------|-----|

### 🐛 Bugs (X issues)
| Severity | Location | Issue | Fix |

### ⚡ Performance (X issues)
| Severity | Location | Issue | Fix |

### 📐 Quality (X issues)
| Severity | Location | Issue | Fix |

### 👏 What's Good
- [positive feedback items]

### 📋 Action Items
1. [ordered by priority]

💡 Dica Pratica

O "Verdict" de 3 opcoes e intencional: APPROVE (pode mergear), REQUEST CHANGES (tem blocker) e NEEDS DISCUSSION (nao e blocker mas precisa conversar). Isso alinha com o workflow de PRs do GitHub e facilita a decisao do time.

👏 Feedback Positivo

Um code review que so aponta problemas desmotiva o time. A secao "What's Good" e obrigatoria na skill para destacar boas praticas, decisoes inteligentes e melhorias em relacao a versoes anteriores.

🎯 Conceito Principal

•Boas praticas: "Excelente uso de early returns para reduzir aninhamento"
•Decisoes de design: "Boa escolha usar Strategy pattern aqui - facilita extensao futura"
•Testes: "Cobertura de testes inclui edge cases importantes"
•Documentacao: "JSDoc completo nas funcoes publicas, facilitara onboarding"

💡 Dica Pratica

Inclua na skill: "Sempre listar pelo menos 3 pontos positivos, mesmo em codigo com muitos problemas. Se nao encontrar nada especifico, reconheca o esforco: 'Codigo bem estruturado em pastas logicas' ou 'Commit messages claros e descritivos'." Reviews que so criticam destroem a cultura de equipe.

📋 Resumo do Modulo

✓

Seguranca primeiro - Injection, auth, data exposure e dependencias

✓

Bugs com foco em edge cases - Null checks, race conditions, error handling

✓

Performance com impacto real - N+1 queries, complexidade, memory leaks

✓

Qualidade alinhada ao projeto - Naming, DRY, SRP, types

✓

Output padronizado com score e verdict - APPROVE, REQUEST CHANGES ou NEEDS DISCUSSION

✓

Feedback positivo obrigatorio - Minimo 3 pontos bons para manter a moral do time

← Modulo Anterior Proximo Modulo →