Code Review — o que é, como funciona a revisão de código e a verificação de PR

O que é Code Review

Code review é uma verificação sistemática do código por colegas antes da integração. No contexto do Git, isso significa: um desenvolvedor cria um pull request com alterações, designa revisores, e eles estudam o diff, deixam comentários e emitem um veredito. Um revisor pode solicitar alterações, aprovar o PR ou deixar um comentário geral.

A revisão de código busca cinco objetivos: melhorar a qualidade do código (encontrar defeitos antes que cheguem à produção), disseminar conhecimento (o revisor aprende novas abordagens, o autor recebe feedback), garantir padrões (verificar conformidade com o estilo de código e decisões arquiteturais), reduzir o bus factor (mais de um desenvolvedor conhece o código) e construir uma cultura de responsabilidade (o autor escreve com mais cuidado sabendo que o código será revisado).

O oposto da revisão de código é um blind commit: um desenvolvedor envia alterações para um ramo compartilhado sem revisão. Esta abordagem é aceitável apenas em projetos de desenvolvedor único ou para hotfix urgentes com revisão posterior. No desenvolvimento profissional em equipe, a revisão de código é uma etapa obrigatória para qualquer alteração, incluindo atualizações de documentação e configuração.

O que verificar no Code Review

A revisão de código deve ser sistemática, não caótica. Revisores experientes verificam o código em uma ordem específica: primeiro arquitetura e lógica, depois testes, depois segurança e desempenho, e apenas no final — estilo e nomenclatura. Esta ordem garante que problemas críticos sejam percebidos antes que o revisor se canse.

Arquitetura e lógica: o código resolve a tarefa, há abstrações excessivas, os princípios SOLID e DRY são seguidos? Código complexo que é difícil de entender na primeira leitura é um sinal de que refatoração é necessária. O revisor deve garantir que o código faça exatamente o que a tarefa especifica e não tenha efeitos colaterais além de sua responsabilidade.

Testes: os novos testes cobrem todos os cenários — positivos, negativos, casos limite. Os testes existentes passam após as alterações? Há testes instáveis que falham inconsistentemente. Segurança: ausência de injeções SQL, XSS, vazamento de dados sensíveis através de logs ou respostas de API. Desempenho: eficiência de algoritmos, consultas excessivas ao banco de dados, vazamento de recursos.

• Arquitetura — correção da solução, conformidade com SOLID, ausência de superengenharia.
• Lógica — tratamento de todos os cenários, incluindo erros e casos limite.
• Testes — cobertura de novas alterações, nenhum teste existente quebrado.
• Segurança — injeções, XSS, CSRF, vazamento de dados através de logs.
• Desempenho — complexidade de algoritmos, consultas N+1, vazamento de memória.

Tamanho da Revisão: por que 400 linhas é o máximo

O limite de tamanho do PR é a métrica mais importante da eficácia da revisão de código. Um estudo da Cisco (2015) e experimentos posteriores da SmartBear e Google mostraram que quando o volume de revisão excede 400 linhas, a capacidade do revisor de encontrar defeitos cai drasticamente. Se um PR excede 400 linhas, os defeitos são detectados com probabilidade não superior ao acaso.

Tamanho ideal: 200–400 linhas por PR. Este volume pode ser revisado em 30–60 minutos mantendo a concentração. O Google recomenda não mais que 200 linhas por rodada de revisão com concentração total. Se as alterações forem maiores, a tarefa deve ser decomposta em vários PRs sequenciais, cada um apresentando uma alteração logicamente completa.

Tempo de revisão: dentro de 24 horas após a criação do PR. Se a revisão se prolongar por vários dias, o contexto da tarefa se perde, e o autor tem que gastar tempo restaurando o contexto ao responder comentários. Equipes com forte cultura de revisão de código estabelecem SLAs: por exemplo, 4 horas para alterações críticas e 24 horas para as regulares.

Como escrever bons comentários de revisão

O tom dos comentários é criticamente importante para a eficácia da revisão de código. Um comentário como “Isso está errado” provoca uma reação defensiva e não fornece informações úteis ao autor. Uma melhor formulação é uma pergunta-sugestão: “O que você acha desta abordagem?”, “Isso pode causar um NPE se user == nil. Talvez adicionar um guard?”. Perguntas são menos confrontadoras e estimulam a discussão.

Um bom comentário inclui três partes: o que está errado, por que é um problema e como corrigir. Exemplo: “Este loop usa O(n²) devido a um contains aninhado, o que pode ser lento com 10k+ registros. Tente substituir por um Set para busca O(1).” Esta formulação simultaneamente identifica o problema, explica sua importância e sugere uma solução — o autor não precisa adivinhar.

GitHub e GitLab suportam sugestões — propostas de alteração de código em linha. Um revisor pode escrever: “```suggestion Filter empty strings before processing```” e o autor pode aplicar a alteração com um clique. Isso acelera correções menores e reduz o número de rodadas de revisão. Para alterações grandes, é melhor escrever um comentário geral em vez de incorporar grandes blocos em uma sugestão.

# Modelo para bom comentário de code review

# RUIM: "This code is wrong"
# BOM: "We may lose data on empty response.
#         If response.data == nil, the guard returns nil,
#         and user sees empty screen without error.
#         Maybe add a fallback error message?"

# Sintaxe de sugestão do GitHub:
# ```suggestion
# let result = try? parse(response, fallback: .defaultValue)
# ```

Fluxo de trabalho de Code Review em equipe

Um fluxo de trabalho eficaz de revisão é construído em quatro etapas. Primeira — o autor prepara o PR: escreve um título claro (por exemplo, “feat: add password reset screen”), adiciona uma descrição das alterações, links para a tarefa no rastreador e instruções de teste. Segunda — o autor designa revisores via auto-assign (com base em CODEOWNERS) ou manualmente.

A terceira etapa — o revisor verifica o código e deixa comentários. A quarta — o autor faz correções, responde aos comentários e solicita uma re-revisão. O ciclo se repete até a aprovação. Após a aprovação, o autor realiza a fusão (ou o bot a faz). A automação via Mergify ou GitHub Auto-merge acelera a etapa final.

Um elemento importante do fluxo de trabalho é a gestão de PRs obsoletos. Se um PR fica sem revisão por mais de 3 dias, o processo é bloqueado. Soluções: rotação de revisores (se o designado estiver indisponível), notificações via Slack/Teams, limite de tempo para revisão (SLA). Em algumas equipes, um PR sem revisão por mais de 7 dias é fechado automaticamente, e o autor cria um novo após sincronizar com main.

• Criação do PR — título claro, descrição, links da tarefa, capturas de tela para alterações de UI.
• Designação — auto-designação via CODEOWNERS ou seleção manual de 1–2 revisores.
• Revisão — verificar na ordem: arquitetura → lógica → testes → segurança → estilo.
• Correções — o autor responde a todos os comentários, corrige problemas bloqueantes, solicita re-revisão.
• Fusão — após aprovação e CI verde, o autor ou o bot realiza a fusão.

Erros comuns de Code Review

O primeiro erro — revisão superficial. O revisor escaneia rapidamente o diff sem se aprofundar na lógica e clica em Approve. Causas: PR grande, prazo, fadiga. Consequências: bugs chegam à produção. Solução: se não há tempo para uma revisão de qualidade — escreva honestamente “Não posso revisar hoje, transfira para amanhã” em vez de uma aprovação formal.

O segundo erro — crítica excessiva (nitpicking). O revisor deixa dezenas de comentários sobre estilo de formatação, nomes de variáveis, detalhes triviais. Isso desmotiva o autor e prolonga a revisão. Solução: StyleGuide e linters devem verificar o estilo automaticamente. Uma pessoa na revisão verifica lógica, arquitetura e segurança.

O terceiro erro — revisão sem perguntas. Se o revisor apenas publica Request Changes e Approve mas não faz perguntas, ele perde a oportunidade de aprender algo novo. O melhor indicador de uma revisão saudável é a presença de discussões onde ambos os lados aprendem algo novo. Se uma revisão é um monólogo de um participante, o processo está quebrado.

• Revisão superficial — Approve sem análise profunda. Solução: não revisar se não tiver tempo.
• Nitpicking — criticar estilo que deveria ser verificado por linter. Solução: automatizar verificações de estilo.
• Preferência pessoal — “Eu teria escrito de outra forma”. Solução: o código deve funcionar, não agradar ao revisor.
• Atraso — revisão superior a 24 horas. Solução: SLA na revisão, escalação em caso de violação.
• Ignorar contexto — revisar código sem entender a tarefa. Solução: ler a descrição do PR antes do diff.