Item01
Título claro: o que muda, em uma linha (ex.: “fix: evita cobrança duplicada no webhook”).
Checklist
O checklist de code review que faz o tech lead te respeitar.
22 itens em 4 blocos: antes de abrir o PR, ao revisar o diff, ao comentar e ao aprovar. No fim, o template de descrição. PR fácil de revisar: contexto claro, diff pequeno, teste do caso de borda e comentários que apontam risco — não ego.
PR fácil de revisarcontextodiff pequenoteste do caso de bordacomentário de risco
Review bom acelera o time. Na mentoria, eu monto o plano de estudo para você virar a referência técnica da vaga que você quer.
Item02
Descrição com: problema, o que mudou, como testar e riscos conhecidos.
Item03
Diff pequeno: menos de ~300 linhas, ou quebrado em commits lógicos.
Item04
Sem misturar feature, bugfix e refatoração no mesmo PR.
Item05
Você já revisou o próprio diff e removeu debug, comentário morto e arquivo gerado.
Item06
Testes novos ou atualizados cobrem o bug e o caso de borda principal.
Item07
Correção: a mudança resolve o problema descrito?
Item08
Casos de borda: entrada vazia, nulo, timeout, concorrência, permissão.
Item09
Nomes: variáveis, funções e arquivos dizem o que fazem?
Item10
Complexidade: dá para entender em uma leitura? Há caminho mais simples?
Item11
Segurança: auth, validação de input, dados sensíveis, SQL/command injection.
Item12
Performance: N+1, loop desnecessário, alocação grande, cache errado.
Item13
Legibilidade: o próximo dev vai entender daqui a 6 meses?
Item14
Comentário acionável: o que está errado e o que mudaria (ou uma pergunta).
Item15
Pergunte em vez de mandar: “O que acontece se X for nulo?” > “Muda isso.”
Item16
Separe bloqueante de sugestão (prefixos: issue / nit / question / suggestion).
Item17
Critique o código, não a pessoa. Zero review de ego (“eu faria diferente”).
Item18
Aponte o risco: bug, segurança, performance ou manutenção — não só estilo.
Item19
Você leu o diff de verdade. “LGTM” em 30 segundos não conta.
Item20
Pedidos bloqueantes resolvidos ou com issue aberta e acordo explícito.
Item21
Teste do bug / caso de borda está no PR ou há motivo documentado para não estar.
Item22
Descrição e commits ainda batem com o que ficou no final.
Modelo pronto para usar
## Problema
[O que estava errado ou o que faltava, em 1–2 linhas.]
## O que mudou
- [Mudança 1]
- [Mudança 2]
## Como testar
1. [Passo]
2. [Passo]
Resultado esperado: […]
## Riscos
- [Risco conhecido / migração / feature flag / rollback]
Júnior espera aprovação. Sênior facilita a revisão.
O júnior espera aprovação. O sênior facilita a revisão e acelera o time.
No próximo PR, escreva a descrição com problema, o que mudou, como testar e riscos.
Para ir além: Guia de code review do Google (eng-practices, em inglês) ↗ · Guia para quem abre o PR (Google eng-practices, em inglês) ↗ · Conventional Comments: prefixos para comentários acionáveis ↗ · Sobre pull request reviews no GitHub (docs oficiais, em inglês) ↗
Conteúdo sobre carreira dev, todo dia: @lucasadvice ↗
Mentoria
Vire a referência que o tech lead confia
Quem facilita a revisão vira a pessoa em quem o tech lead confia — e é essa confiança que abre promoção e as melhores oportunidades. A mentoria acelera esse caminho: plano de estudo para a vaga que você quer, LinkedIn que mostra o seu trabalho e as empresas certas para conversar.