8 min leitura • Guide 111 of 877
Mantendo Padrões Consistentes de Code Review
Padrões de code review eliminam debates subjetivos definindo o que significa "bom o suficiente" para seu time. As integrações de GitHub, GitLab, e Bitbucket do GitScrum mostram atividade de pull requests junto ao rastreamento de tarefas, enquanto documentação NoteVault e checklists de revisão ajudam times a manter expectativas consistentes, reduzir tempo de revisão, e transformar code review em oportunidade de aprendizado em vez de gargalo.
Estabelecendo Padrões
Framework Critérios Review
DIMENSÕES CODE REVIEW:
┌─────────────────────────────────────────────────────────────┐
│ O QUE REVISAR │
├─────────────────────────────────────────────────────────────┤
│ │
│ TIER 1: DEVE PASSAR (Bloqueante) │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ☐ Funciona corretamente (implementa requisitos) ││
│ │ ☐ Sem bugs óbvios ou casos borda ││
│ │ ☐ Testes passam (unit, integração) ││
│ │ ☐ Sem vulnerabilidades segurança introduzidas ││
│ │ ☐ Sem mudanças breaking sem path migração ││
│ │ ☐ Sem dados sensíveis expostos (keys, passwords) ││
│ │ ││
│ │ Status: PR não pode mergear até tudo checado ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ TIER 2: DEVERIA PASSAR (Alta Prioridade) │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ☐ Código é legível e compreensível ││
│ │ ☐ Segue convenções naming do time ││
│ │ ☐ Tratamento erros é apropriado ││
│ │ ☐ Performance é aceitável ││
│ │ ☐ Tem cobertura testes suficiente ││
│ │ ☐ Documentação atualizada se necessário ││
│ │ ││
│ │ Status: Abordar antes de merge, ou criar tarefa follow ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ TIER 3: BOM TER (Sugestões) │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ☐ Poderia ser mais elegante/conciso ││
│ │ ☐ Preferências menores de estilo ││
│ │ ☐ Abordagens alternativas a considerar ││
│ │ ☐ Oportunidades refactoring para depois ││
│ │ ││
│ │ Status: Não-bloqueante, autor decide se abordar ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ DOCUMENTAR NO NOTEVAULT: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Criar documento "Padrões Code Review" para time ││
│ │ Incluir exemplos para cada tier ││
│ │ Referenciar no template PR ││
│ │ Revisar trimestralmente para atualizações ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Convenção Comentários
TIPOS COMENTÁRIOS REVIEW:
┌─────────────────────────────────────────────────────────────┐
│ PREFIXOS COMENTÁRIOS CLAROS │
├─────────────────────────────────────────────────────────────┤
│ │
│ BLOQUEANTE: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ [BLOQUEANTE] Isso causará null pointer em produção ││
│ │ ││
│ │ Significado: PR não pode mergear até abordar ││
│ │ Responsabilidade revisor: Explicar por que é bloqueante ││
│ │ Resposta autor: Deve corrigir ou discutir ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ PERGUNTA: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ [PERGUNTA] Por que estamos cacheando isso por 24 horas? ││
│ │ ││
│ │ Significado: Preciso entender antes de aprovar ││
│ │ Responsabilidade revisor: Curiosidade genuína ││
│ │ Resposta autor: Explicar raciocínio ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ SUGESTÃO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ [SUGESTÃO] Considere usar Optional aqui em vez ││
│ │ ││
│ │ Significado: Ideia melhoria não-bloqueante ││
│ │ Responsabilidade revisor: Propor alternativa ││
│ │ Resposta autor: Aceita ou não, sem discussão req. ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ NIT: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ [NIT] Typo no nome variável: "recieve" → "receive" ││
│ │ ││
│ │ Significado: Trivial, corrigir se fácil ││
│ │ Responsabilidade revisor: Manter estes mínimos ││
│ │ Resposta autor: Fix rápido ou ignorar ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ELOGIO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ [BOM] Solução limpa, aprendi algo aqui ││
│ │ ││
│ │ Significado: Feedback positivo, não só crítica ││
│ │ Responsabilidade revisor: Ser genuíno, não condescenden ││
│ │ Resposta autor: Nenhuma necessária, faz bem ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Integração GitScrum
Rastreando Reviews
CONECTANDO PR A TAREFAS:
┌─────────────────────────────────────────────────────────────┐
│ VISIBILIDADE NO GITSCRUM │
├─────────────────────────────────────────────────────────────┤
│ │
│ INTEGRAÇÃO GITHUB/GITLAB/BITBUCKET: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 1. Developer referencia tarefa no PR/commit ││
│ │ "Fix timeout login usuário [GS-1234]" ││
│ │ ││
│ │ 2. Atividade PR aparece na tarefa GitScrum ││
│ │ Tarefa #1234 mostra: ││
│ │ • PR aberto ││
│ │ • Reviews solicitados ││
│ │ • Comentários adicionados ││
│ │ • Status merge ││
│ │ ││
│ │ 3. Time vê contexto completo sem trocar ferramentas ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ AUTOMAÇÃO COLUNA WORKFLOW: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Considere workflow: ││
│ │ ││
│ │ Em Dev → Em Review → Pronto QA → Pronto ││
│ │ ││
│ │ Coluna "Em Review" = PR aberto, aguardando aprovação ││
│ │ ││
│ │ Mover para Em Review quando: ││
│ │ • PR criado e pronto para review ││
│ │ • Não ainda WIP (draft PR) ││
│ │ ││
│ │ Mover para Pronto QA quando: ││
│ │ • PR aprovado e mergeado ││
│ │ • Deployado para ambiente teste ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Eficiência Review
Dimensionando PRs Corretamente
GUIAS TAMANHO PR:
┌─────────────────────────────────────────────────────────────┐
│ PRs MENORES = MELHORES REVIEWS │
├─────────────────────────────────────────────────────────────┤
│ │
│ LIMITES TAMANHO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Linhas Alteradas │ Qualidade Review │ Ação ││
│ │ ─────────────────┼──────────────────┼──────────────── ││
│ │ < 200 linhas │ ✅ Completo │ Tamanho ideal ││
│ │ 200-400 linhas │ ⚠️ Adequado │ Aceitável ││
│ │ 400-800 linhas │ ❌ Apressado │ Considerar dividir││
│ │ > 800 linhas │ ❌ Rubber stamp │ Deve dividir ││
│ │ ││
│ │ Exceção: Refactors grandes com padrões claros ││
│ │ Exceção: Código gerado ou arquivos config ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ ESTRATÉGIAS DIVISÃO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Feature grande demais para um PR: ││
│ │ ││
│ │ Opção 1: Slicing vertical ││
│ │ ┌─────────────────────────────────────────────────────┐ ││
│ │ │ PR 1: Happy path básico (slice fino end-to-end) │ ││
│ │ │ PR 2: Tratamento erros │ ││
│ │ │ PR 3: Casos borda │ ││
│ │ │ PR 4: Otimização performance │ ││
│ │ └─────────────────────────────────────────────────────┘ ││
│ │ ││
│ │ Opção 2: Camada por camada ││
│ │ ┌─────────────────────────────────────────────────────┐ ││
│ │ │ PR 1: Schema banco + migrações │ ││
│ │ │ PR 2: Endpoints API backend │ ││
│ │ │ PR 3: UI frontend │ ││
│ │ │ PR 4: Integração e testes │ ││
│ │ └─────────────────────────────────────────────────────┘ ││
│ │ ││
│ │ Rastrear no GitScrum: ││
│ │ Tarefa principal com subtarefas para cada PR ││
│ │ Vincular todos PRs à tarefa pai para visibilidade ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘
Lidando com Desacordos
Resolvendo Conflitos
QUANDO REVISOR E AUTOR DISCORDAM:
┌─────────────────────────────────────────────────────────────┐
│ RESOLUÇÃO CONFLITOS CONSTRUTIVA │
├─────────────────────────────────────────────────────────────┤
│ │
│ FRAMEWORK DECISÃO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ ││
│ │ ┌────────────────────────────────────────────────────┐ ││
│ │ │ É objetivamente errado (bug, segurança, quebra)? │ ││
│ │ └──────────────────┬─────────────────────────────────┘ ││
│ │ │ ││
│ │ ┌─────────┴─────────┐ ││
│ │ Sim Não ││
│ │ │ │ ││
│ │ ▼ ▼ ││
│ │ ┌─────────────────┐ ┌──────────────────────────────┐ ││
│ │ │ Deve corrigir │ │ Existe padrão do time? │ ││
│ │ │ (Revisor ganha) │ └───────────┬──────────────────┘ ││
│ │ └─────────────────┘ │ ││
│ │ ┌─────────┴─────────┐ ││
│ │ Sim Não ││
│ │ │ │ ││
│ │ ▼ ▼ ││
│ │ ┌─────────────────┐ ┌────────────────┐ ││
│ │ │ Seguir padrão │ │ Autor decide │ ││
│ │ │ (Ninguém ganha, │ │ (Autor ganha, │ ││
│ │ │ time ganha) │ │ é código dele)│ ││
│ │ └─────────────────┘ └────────────────┘ ││
│ │ ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ CAMINHO ESCALAÇÃO: │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ Se não conseguem concordar após 2 rodadas: ││
│ │ ││
│ │ 1. Limitar tempo discussão (15 min call máximo) ││
│ │ 2. Se ainda sem acordo → trazer terceira pessoa ││
│ │ 3. Terceira pessoa decide, decisão é final ││
│ │ ││
│ │ Nunca: Bloquear PR indefinidamente por pref. estilo ││
│ │ Nunca: Tornar pessoal ("você sempre faz X") ││
│ │ Sempre: Focar no código, não no coder ││
│ └─────────────────────────────────────────────────────────┘│
│ │
└─────────────────────────────────────────────────────────────┘