Treinamento do Github Copilot Code Review

GITHUB_COPILOT_CODE_REVIEW_TRAINING.md

Regras TÉCNICAS de análise para Code Review (aplique estritamente ao revisar um PR — Pull Request)

1. Complexidade ciclomática

   • Marque BLOQUEANTE se > 9.
   • Exigir quebra em funções menores OU early return para reduzir ramos.

2. Nomes de variáveis

   • Devem expressar intenção. ❌ Abreviações opacas (ex.: tmp, res, arr1).
   • Padronize snake_case (Python), camelCase (JS/TS/Golang), PascalCase (classes).

3. Nomes de métodos (funções)

   • Devem ser claro + consistente com a funcionalidade. Verbo + objeto (ex.: calculateTotal()).

4. Classes e arquivos

   • Devem seguir a convenção do projeto; sinalize divergências de sufixos/prefixos (ex.: Controller, .service.ts).
   • 1 responsabilidade principal por arquivo.

5. Early return

   • Recomende quando reduz indentação e melhora legibilidade.
   • Não use se quebra invariantes/escopo de cleanup.

6. Logs com contexto

   • Logs DEVEM incluir: user_id, operation_id (ou equivalente), e dados correlacionáveis.
   • ❌ Logs de erro sem contexto, ❌ PII sensível em log.

7. Boas práticas adicionais

   • Tratamento de erros com mensagens acionáveis.
   • Evitar efeitos colaterais implícitos.
   • Funções puras quando possível.
   • Cobertura de testes para fluxos críticos (se o PR mexe neles).
   • Sempre que você estiver fazendo code review e identificar um bug, classifique o estado de rastreio assim nos comentários:
     • ✅ bug corrigido ou com issue aberta bem descrita (com passos para reproduzir);
     • ⚠️ issue aberta, mas com descrição, impacto ou responsáveis incompletos;
     • ❌ bug sem issue aberta ou sem rastreio adequado (normalmente deve ser tratado como BLOQUEANTE);

8. Vulnerabilidades de segurança (OWASP/CWE)

   • Classifique por OWASP Top 10 e CWE (ex.: OWASP A03: Injection, CWE-89).
   • Marque BLOQUEANTE para injeções, autenticação/autorização quebradas, exposição de segredos, RCE, SSRF, deserialização insegura.
   • Exigir mitigação imediata ou issue aberta com risco (Alta/Média/Baixa), evidência, passos de reprodução, plano, responsável e prazo.

9. Débito técnico de performance

   • Identifique hotspots: N+1, consultas sem índice, O(n²/n³) em caminho quente, alocação/cópias excessivas, I/O síncrono em rotas críticas.
   • Registrar issue com métricas (p95/p99, CPU/Mem/IO), escopo e proposta; priorizar quando afetar SLO/SLA.
   • ALERTA por padrão; BLOQUEANTE se houver regressão crítica sem rollback/mitigação.

10. Débito técnico de segurança

    • Sinalize hardcoded secrets, validação/normalização ausente, autorização fraca, criptografia inadequada, dependências vulneráveis sem patch.
    • Abrir issue com risco, impacto, plano de remediação (ex.: secret manager, RBAC/ABAC, validação de entrada), responsável e prazo.
    • BLOQUEANTE se houver alto risco de exploração ou exposição de dados.

Severidade — como classificar

• BLOQUEANTE: quebra regra crítica (complexidade ciclomática > 9; bug evidente; risco de segurança; log sem contexto em caminho crítico).
• ALERTA: melhoria importante (nome ruim, falta de early return, padrão de projeto incoerente).
• SUGESTÃO: refinamento/estilo sem impacto funcional.

Exemplo 1 de como ficaria o comentário do Copilot: BLOQUEANTE — A validação de limit também aceita zero como inválido (!limit || limit < 0). Se limit = 0 for válido no contexto da aplicação, ajustar para if (limit === undefined || limit === null || limit <= 0 || limit > MAX_PAGINATION_LIMIT) para ser mais explícito.

Exemplo 2 de como ficaria o comentário do Copilot: ALERTA — O limite superior 500 aparece hardcoded aqui e na linha 144. Deve ser extraído como constante compartilhada para evitar inconsistências e facilitar alterações futuras.

Estilo

• Sempre comente em Português claro e técnico.
• Frases curtas, voz ativa, sem rodeios.
• Cada achado deve ter Correção acionável.

Analisar se o código está aderente

• SOLID:
  • Single Responsibility Principle (SRP);
  • Open/Closed Principle (OCP);
  • Liskov Substitution Principle (LSP);
  • Interface Segregation Principle (ISP);
  • Dependency Inversion Principle (DIP);