10 min leitura • Guide 73 of 877
Implementando Processos Efetivos de Code Review
Code review é mais que encontrar bugs—é um portão de qualidade, mecanismo de compartilhar conhecimento, e ferramenta de alinhamento de time. Processos de review efetivos balanceiam profundidade com velocidade, garantindo altos padrões sem se tornar gargalo. As integrações Git do GitScrum conectam reviews ao seu fluxo de projeto, mantendo visibilidade e responsabilidade através do processo de desenvolvimento.
Fundamentos de Code Review
Propósito do Code Review
POR QUE REVISAMOS CÓDIGO:
┌─────────────────────────────────────────────────────────────┐
│ OBJETIVOS ALÉM DE ENCONTRAR BUGS │
├─────────────────────────────────────────────────────────────┤
│ │
│ OBJETIVOS PRIMÁRIOS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 🐛 DETECÇÃO DE DEFEITOS ││
│ │ Capturar bugs antes de chegarem a produção ││
│ │ Erros lógica, casos borda, problemas segurança ││
│ │ ││
│ │ 📚 COMPARTILHAR CONHECIMENTO ││
│ │ Difundir entendimento através do time ││
│ │ Reduzir silos conhecimento, fator bus ││
│ │ ││
│ │ 📏 APLICAÇÃO DE PADRÕES ││
│ │ Manter padrões código consistentes ││
│ │ Alinhamento arquitetura, consistência estilo ││
│ │ ││
│ │ 🎓 MENTORIA ││
│ │ Ensinar e aprender através do diálogo review ││
│ │ Desenvolvimento junior, supervisão senior ││
│ │ ││
│ │ 🤝 PROPRIEDADE COLETIVA ││
│ │ Múltiplas pessoas entendem cada mudança ││
│ │ Melhor manutenção, debugging mais rápido ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Integrando com GitScrum
Visibilidade de PR
INTEGRAÇÃO GIT GITSCRUM:
┌─────────────────────────────────────────────────────────────┐
│ CONECTANDO PULL REQUESTS A TAREFAS │
├─────────────────────────────────────────────────────────────┤
│ │
│ VINCULAÇÃO AUTOMÁTICA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Quando desenvolvedores incluem ID tarefa em branch/PR: ││
│ │ ││
│ │ Nomeação branch: ││
│ │ feature/PROJ-123-autenticacao-usuario ││
│ │ ││
│ │ Título PR: ││
│ │ PROJ-123: Adicionar fluxo autenticação usuário ││
│ │ ││
│ │ GitScrum automaticamente: ││
│ │ ├── Vincula PR à tarefa PROJ-123 ││
│ │ ├── Mostra status PR no cartão tarefa ││
│ │ ├── Atualiza feed atividade ││
│ │ └── Notifica assignees de eventos PR ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ VISIBILIDADE QUADRO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Coluna Code Review mostra status PR: ││
│ │ ││
│ │ ┌───────────┐ ┌───────────┐ ┌───────────┐ ││
│ │ │ PROJ-123 │ │ PROJ-456 │ │ PROJ-789 │ ││
│ │ │ Auth flow │ │ Dashboard │ │ Relatórios│ ││
│ │ │ │ │ │ │ │ ││
│ │ │ 🟢 PR #456 │ │ 🟡 PR #461 │ │ 🔴 PR #458 │ ││
│ │ │ Aprovado │ │ Revisando │ │ Mudanças │ ││
│ │ └───────────┘ └───────────┘ └───────────┘ ││
│ │ ││
│ │ Filtros: [Todos PRs] [Precisa Review] [Aprovado] ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Fluxo de Review
INTEGRAÇÃO PROCESSO REVIEW:
┌─────────────────────────────────────────────────────────────┐
│ FLUXO REVIEW DE PONTA A PONTA │
├─────────────────────────────────────────────────────────────┤
│ │
│ 1. TAREFA INICIADA → EM PROGRESSO │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Desenvolvedor: ││
│ │ • Move tarefa para "Em Progresso" ││
│ │ • Cria branch com ID tarefa ││
│ │ • Desenvolve e testa localmente ││
│ └─────────────────────────────────────────────────────────┘│
│ ↓ │
│ 2. PR CRIADO → EM REVIEW │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Desenvolvedor: ││
│ │ • Abre PR com ID tarefa no título ││
│ │ • GitScrum auto-move tarefa para "Code Review" ││
│ │ • Solicita reviewers ││
│ └─────────────────────────────────────────────────────────┘│
│ ↓ │
│ 3. CICLO REVIEW │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Reviewers: ││
│ │ • Revisam código no GitHub/GitLab ││
│ │ • Deixam comentários, aprovam, ou solicitam mudanças ││
│ │ ││
│ │ Tarefa reflete: ││
│ │ • Status review (pendente/aprovado/mudanças) ││
│ │ • Status CI (passando/falhando) ││
│ │ • Contagem comentários ││
│ └─────────────────────────────────────────────────────────┘│
│ ↓ │
│ 4. APROVADO → PRONTO PARA MERGE │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Todos reviewers aprovaram: ││
│ │ • Status PR mostra "Aprovado" ││
│ │ • Desenvolvedor ou tech lead faz merge ││
│ └─────────────────────────────────────────────────────────┘│
│ ↓ │
│ 5. MERGED → FEITO │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ No merge: ││
│ │ • GitScrum pode auto-mover tarefa para "Feito" ││
│ │ • Ou mover para "Deployed" para tracking deploy ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Guias de Review
Para Autores
ENVIANDO CÓDIGO PARA REVIEW:
┌─────────────────────────────────────────────────────────────┐
│ PREPARANDO REVIEWERS PARA SUCESSO │
├─────────────────────────────────────────────────────────────┤
│ │
│ ANTES DE SOLICITAR REVIEW: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ □ Auto-revisar mudanças primeiro ││
│ │ □ Rodar todos testes localmente (devem passar) ││
│ │ □ Verificar linting/formatação passa ││
│ │ □ Remover código debug, console.log, TODOs ││
│ │ □ Verificar PR tamanho razoável (<400 linhas) ││
│ │ □ Adicionar testes para nova funcionalidade ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PRs PEQUENOS, FOCADOS: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Tamanho PR │ Tempo Review │ Qualidade ││
│ │─────────────────┼─────────────────┼─────────────────────││
│ │ < 100 linhas │ 15-30 min │ Minuciosa ││
│ │ 100-400 linhas │ 30-60 min │ Boa ││
│ │ 400-800 linhas │ 60-90 min │ Declinando ││
│ │ > 800 linhas │ Freq. olhado │ Pobre (dividir PR!) ││
│ │ │ por cima │ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ RESPONDENDO A FEEDBACK: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ✓ Responder a cada comentário ││
│ │ ✓ Pedir esclarecimento se não claro ││
│ │ ✓ Explicar raciocínio se discordar ││
│ │ ✓ Push fixes como novos commits (rastreabilidade) ││
│ │ ✓ Re-solicitar review quando pronto ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Para Reviewers
DANDO REVIEWS EFETIVOS:
┌─────────────────────────────────────────────────────────────┐
│ MELHORES PRÁTICAS REVIEW │
├─────────────────────────────────────────────────────────────┤
│ │
│ MENTALIDADE REVIEW: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ✓ Revisar código, não a pessoa ││
│ │ ✓ Assumir intenção positiva ││
│ │ ✓ Considerar múltiplas abordagens válidas ││
│ │ ✓ Ser explícito sobre severidade (bloqueante vs sugestão││
│ │ ✓ Oferecer alternativas, não só crítica ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ TIPOS COMENTÁRIO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ BLOQUEANTE (Deve arrumar): ││
│ │ "🔴 BLOQUEANTE: Este SQL é vulnerável a injeção. ││
│ │ Usar queries parametrizadas." ││
│ │ ││
│ │ SUGESTÃO (Deveria considerar): ││
│ │ "💡 SUGESTÃO: Considere usar async/await aqui ││
│ │ para melhor legibilidade. Não bloqueante mas ajuda." ││
│ │ ││
│ │ PERGUNTA (Precisa esclarecimento): ││
│ │ "❓ PERGUNTA: Por que cacheamos isso por 24 horas? ││
│ │ Há um requisito específico?" ││
│ │ ││
│ │ NIT (Menor, opcional): ││
│ │ "📝 NIT: Typo no nome variável 'recieve' → 'receive'" ││
│ │ ││
│ │ ELOGIO (Feedback positivo): ││
│ │ "👍 Boa abordagem! Isso trata os casos borda ││
│ │ elegantemente." ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ EXPECTATIVAS TEMPO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Solicitações review devem ser tratadas dentro de: ││
│ │ ││
│ │ Primeira resposta: < 4 horas durante horário trabalho ││
│ │ Review completo: < 1 dia útil ││
│ │ Re-review: < 4 horas (mudanças menores) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Automatização
Integração CI
VERIFICAÇÕES AUTOMATIZADAS ANTES DE REVIEW:
┌─────────────────────────────────────────────────────────────┐
│ DEIXAR MÁQUINAS VERIFICAREM O QUE FAZEM MELHOR │
├─────────────────────────────────────────────────────────────┤
│ │
│ AUTOMATIZAÇÃO PRÉ-REVIEW: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Pipeline CI (deve passar antes de review): ││
│ │ ││
│ │ □ Build compila com sucesso ││
│ │ □ Todos testes passam ││
│ │ □ Cobertura código acima limiar ││
│ │ □ Linting passa (sem problemas estilo) ││
│ │ □ Formatação correta (Prettier, Black, etc.) ││
│ │ □ Scan segurança passa ││
│ │ □ Verificação tipos passa (TypeScript, mypy) ││
│ │ ││
│ │ Se CI falha → Autor deve arrumar antes de solicitar ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ VISIBILIDADE GITSCRUM: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Tarefa mostra status CI: ││
│ │ ││
│ │ ┌─────────────────────────────────────────────────────┐ ││
│ │ │ PROJ-123: Autenticação Usuário │ ││
│ │ │ │ ││
│ │ │ PR #456 Status CI: │ ││
│ │ │ ✓ Build Passou │ ││
│ │ │ ✓ Testes 142/142 passaram │ ││
│ │ │ ✓ Linting Sem problemas │ ││
│ │ │ ✓ Cobertura 87% (≥80% requerido) │ ││
│ │ │ ✓ Segurança Sem vulnerabilidades │ ││
│ │ │ │ ││
│ │ │ Pronto para review ✓ │ ││
│ │ └─────────────────────────────────────────────────────┘ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Anti-Padrões Comuns
O Que Evitar
ANTI-PADRÕES CODE REVIEW:
┌─────────────────────────────────────────────────────────────┐
│ PRÁTICAS QUE PREJUDICAM EFETIVIDADE REVIEW │
├─────────────────────────────────────────────────────────────┤
│ │
│ ✗ RUBBER STAMPING │
│ Problema: Aprovar sem ler │
│ Sinal: Aprovações rápidas, sem comentários, bugs prod │
│ Correção: Exigir tempo mínimo, rastrear taxa comentários │
│ │
│ ✗ GATEKEEPING │
│ Problema: Usar review para bloquear por estilo pessoal │
│ Sinal: Mesma pessoa bloqueia tudo, baseado em opinião │
│ Correção: Padrões claros, caminho escalação, rotacionar │
│ │
│ ✗ REVIEW SEM FIM │
│ Problema: Novos comentários após cada rodada │
│ Sinal: 5+ rodadas review, metas mudando │
│ Correção: Todo feedback primeira rodada, delimitar tempo │
│ │
│ ✗ DESIGN EM CODE REVIEW │
│ Problema: Questionar arquitetura após código escrito │
│ Sinal: "Por que fazemos assim?" no PR │
│ Correção: Reviews design antes coding, RFCs mudanças │
│ │
└─────────────────────────────────────────────────────────────┘
Melhores Práticas
Fazer
PRÁTICAS CODE REVIEW EFETIVAS:
✓ AUTOMATIZAR VERIFICAÇÕES ESTILO
Deixar linters tratar formatação, focar em lógica
✓ MANTER PRs PEQUENOS
<400 linhas habilita review minucioso
✓ RESPONDER RAPIDAMENTE
<4 horas primeira resposta mantém fluxo
✓ SER ESPECÍFICO EM FEEDBACK
Mostrar alternativa, não só problema
✓ ETIQUETAR SEVERIDADE COMENTÁRIO
Bloqueante vs sugestão vs nit
Não Fazer
ARMADILHAS CODE REVIEW:
✗ REVISAR PRs GIGANTES
>800 linhas será olhado por cima, não revisado
✗ DEBATES ESTILO EM REVIEWS
Automatizar com formatters, ou documentar padrões
✗ APROVAR SEM LER
Derrota propósito completamente
✗ SER DURO
Code review é para código, não pessoa