Skills: Skill de Revisão de Código

Última atualização: 2026-08-31

A revisão de código é a primeira linha de defesa da qualidade — um excelente Skill de revisão é como ter um revisor sênior incansável na equipe.


1. Design das dimensões de revisão

(1) Dimensões centrais de revisão

Dimensão Itens de verificação Severidade
Segurança Injeção SQL, XSS, chaves hardcoded, dependências inseguras 🔴 Crítico
Desempenho Consultas N+1, vazamentos de memória, loops desnecessários 🟡 Importante
Legibilidade Convenções de nomenclatura, comprimento de funções, adequação de comentários 🟢 Sugestão
Melhores práticas Tratamento de erros, princípios SOLID, DRY 🟡 Importante
Cobertura de testes Testes unitários, condições de contorno, caminhos de erro 🟡 Importante

(2) Dimensões específicas por linguagem

MARKDOWN
## Verificações extras para Python
- Completude de type hints
- Formato de docstring (estilo Google/NumPy)
- f-string vs format/concat
- Escopo de captura de exceção (evitar bare except)

## Verificações extras para TypeScript
- Uso do tipo any
- Validade de type assertion
- Completude de definição de interface
- Anotações de propriedades opcionais

2. Design do fluxo de revisão

(1) Fluxo padrão

TEXT 📖 Somente leitura
Fluxo de revisão de código
├── 1. Coletar mudanças
│   ├── Ler git diff (lista de arquivos alterados)
│   └── Determinar escopo da revisão
├── 2. Revisão por arquivo
│   ├── Ler arquivo
│   ├── Grep para contexto relacionado
│   └── Verificar por dimensão
├── 3. Gerar relatório
│   ├── Ordenar por severidade
│   ├── Fornecer sugestões de correção concretas
│   └── Incluir exemplos de código
└── 4. Avaliação sumária
    ├── Pontuação geral
    └── Recomendação de merge

(2) Revisão incremental vs completa

Tipo Escopo Caso de uso
Revisão incremental Revisar apenas partes alteradas Revisão de PR/MR
Revisão completa Revisar módulo inteiro Revisão de código de novo membro, verificação pós-refatoração

3. Formato do relatório de revisão

(1) Template de saída padrão

MARKDOWN
## Relatório de Revisão de Código

### 📊 Visão geral
- Arquivos revisados: 3
- Problemas encontrados: 5 (🔴 1 / 🟡 2 / 🟢 2)
- Pontuação geral: 7/10
- Recomendação: ⚠️ Merge após corrigir problemas críticos

### 🔴 Problemas críticos

**[SEC-001] Risco de injeção SQL**
📍 Localização: src/auth/login.py:42
📝 Uso de concatenação de strings para construir consulta SQL
✅ Sugestão:
```python
query = "SELECT * FROM users WHERE name = ?"
cursor.execute(query, (username,))

🟡 Problemas importantes

...

🟢 Sugestões de melhoria

...


### (2) Sistema de pontuação

```text
Regras de pontuação:
- 🔴 Problema crítico: -3 cada
- 🟡 Problema importante: -1 cada
- 🟢 Sugestão: -0.5 cada
- Pontuação base: 10
- Pontuação mínima: 0

Recomendação de merge:
- ≥ 8 pontos: ✅ Recomendar merge
- 5-7 pontos: ⚠️ Merge após correções
- < 5 pontos: ❌ Não recomendar merge

4. Skill de revisão na prática

▶ Exemplo: Skill de revisão de dimensão completa

Alice criou um Skill de revisão padronizado para a equipe:

YAML
---
name: full-review
description: "Revisão de código de dimensão completa"
triggers:
  - keyword: "full-review"
tools:
  - Read
  - Grep
  - Glob
  - Bash
---
MARKDOWN
## Fluxo de revisão

1. Glob para determinar o escopo de arquivos a revisar
2. Para cada arquivo, verificar por dimensão:
   - Segurança: Grep para padrões perigosos
   - Desempenho: Read para analisar complexidade algorítmica
   - Legibilidade: Verificar nomenclatura e estrutura
   - Testes: Confirmar cobertura de testes
3. Agregar e exibir relatório de revisão

Bob comentou: "Relatórios padronizados tornam os resultados da revisão claros à primeira vista — sinal vermelho deve corrigir, sinal amarelo verificar a situação, sinal verde é bônus."


❓ Perguntas Frequentes

P: Revisões excessivamente rigorosas atrasam o desenvolvimento? R: Sim. Recomendamos dois níveis — revisão de PR verifica apenas segurança e lógica-chave; revisões completas periódicas cobrem todas as dimensões. P: A revisão por IA pode substituir a revisão humana? R: Não completamente. A IA é excelente em correspondência de padrões e varredura de segurança; humanos são excelentes em revisão de arquitetura e julgamento de lógica de negócio. Os dois se complementam melhor. P: Como evitar que relatórios de revisão fiquem muito longos? R: Configure filtro de severidade; por padrão, exiba apenas problemas 🟡 e acima. Sugestões 🟢 são saída opcional.


📖 Resumo


📝 Exercícios

  1. Básico (dificuldade⭐): Crie um Skill de revisão de segurança que verifique apenas injeção SQL, XSS e chaves hardcoded.
  2. Intermediário (dificuldade⭐⭐): Crie um Skill de revisão de dimensão completa que exiba um relatório de revisão padrão com pontuação e recomendação de merge.
  3. Avançado (dificuldade⭐⭐⭐): Crie um Skill de revisão incremental que revise apenas as mudanças no git diff e ajuste automaticamente as dimensões de revisão por linguagem.
Web-Tutorial.com

Equipe Técnica Web-Tutorial

Uma plataforma de tutoriais mantida por diversos desenvolvedores. Cada tutorial é escrito e revisado por profissionais da área correspondente. Trabalhamos para manter nosso conteúdo preciso e confiável — se encontrar algum problema, avise-nos.

100%