Pirâmide de Code Review

Em muitos times, revisão de código virou liturgia: gestos corretos, intenção ausente. O PR é aprovado com "LGTM" e ninguém questiona design ou risco.

Esta apresentação propõe uma abordagem estruturada usando a Pirâmide de Code Review — inspirada no trabalho de Gunnar Morling — para separar o que é mecânico (e deve ser automatizado) do que exige julgamento humano.

Conteúdo:
• A origem do code review: de Fagan (1976) ao Pull Request
• Evolução dos sistemas de controle de versão: centralizado vs. distribuído
• Os 5 níveis da pirâmide: estilo, segurança, comportamento, design e produto
• Exemplos práticos em React, TypeScript, Java e Kotlin
• O papel da IA: onde agentes ajudam e onde o humano continua essencial
• Boas práticas e checklist por camada

Artigo completo: https://notes.clementino.me/blog/piramide-code-review

Transcript

1. Pirâmide de Code Review O que automatizar e o que manter humano 1
2. Liturgia corporativa Liturgia: repetir um rito sem questionar o porquê. Em muitos times, revisão de código virou liturgia corporativa. Um item na descrição de cargo. Uma etapa obrigatória. Isso é claramente uma má prática. O desenvolvedor abre o PR, outro aprova com "LGTM", e o código vai para produção. “ “ 2
4. O problema real Revisão de código não deveria ser formalidade vazia. É um momento para discussão técnica sobre qualidade, riscos e evolução. Quando vira etapa protocolar, perde o valor. Pior: cria falsa sensação de segurança. O problema não é revisar código. É fazer de conta que revisou. 4
5. A pergunta inevitável A resposta: Pirâmide de Code Review Base automatizada. Topo humano. O que dá para automatizar sem esvaziar o valor humano da revisão? “ “ 5
6. De onde vem o code review 1976 — Michael Fagan (IBM) formaliza inspeções de software Décadas depois, processos mais leves ganham força: patches por e-mail, discussões em lista, revisão incremental A evolução dos sistemas de controle de versão viabilizou a transição 6
7. Centralizado vs. Distribuído CVS / SVN Servidor central único, modelo linear, commit direto no trunk Git / Mercurial (2005) Cópia completa local, branch barato, fork como fluxo natural 7
10. O padrão se consolida O modelo distribuído casou com o open source. GitHub (2008) transformou isso em algo visual e assíncrono. Padrão consolidado: branch → diff → revisão → merge 10
12. Nomes no ecossistema Pull Request (PR) — GitHub, Bitbucket Merge Request (MR) — GitLab Change / Patch Set — Gerrit Change List (CL) — Perforce Differential Revision — Phabricator Mudou o nome, não a essência: propor, revisar coletivamente, integrar. 12
14. Da Pirâmide de Testes à Pirâmide de Review Mike Cohn (2009): Pirâmide de Testes Muitos testes unitários na base, poucos E2E no topo. Mesma intuição aplicada à revisão: Base: mecânico e determinístico → automatize Topo: contexto, julgamento, experiência → preserve para o humano 14
16. A Pirâmide de Code Review Três perguntas: 1. O que deve ser automatizado? 2. O que pode ser parcialmente automatizado? 3. O que não deveria ser automatizado? Base visual: Gunnar Morling 16
17. - Is the project's formatting style applied? - Does it adhere to agreed on naming conventions - Is it DRY? - Is the code sufficiently "readable" (method lengths, etc.) - Are all tests passing? - Are new features reasonably tested? - Are corner cases tested? - Is it using unit tests where possible, integration tests where necessary? - Are there tests for NFRs, e.g. performance? - New features reasonably documented? - Are the relevant kinds of docs covered: README, API docs, user guide, reference docs, etc.? - Are docs understandable, are there no significant typos and grammar mistakes? - Does it satisfy the original requirements? - Is it logically correct? - Is there no unnecessary complexity? - Is it robust (no concurrency issues, proper error handling, etc.)? - Is it performant? - Is it secure (e.g. no SQL injections, etc.) - Is it observable (e.g. metrics, logging, tracing, etc.)? - Do newly added dependencies pull their weight? Is their license acceptable? - API as small as possible, as large as needed? - Is there one way of doing one thing, not multiple ones? - Is it consistent, does it follow the principle of least surprises? - Clean split of API/internals, without internals leaking in the API? - Are there no breaking changes to user-facing parts (API classes, configuration, metrics, log formats, etc.)? - Is a new API generally useful and not overly specific? Code Style Tests Documentation Implementation Semantics API Semantics Questions to ask: Questions to ask: Questions to ask: Questions to ask: Questions to ask: Automate here! Focus your review efforts here! The Code Review Pyramid Licensed under CC BY-SA 4.0 (C) @gunnarmorling Larger effort for changes later on Smaller effort for changes later on 17
18. Nível 1 — Estilo e formatação Regras sem subjetividade. Se é determinístico, não consome tempo humano. React/TS: Prettier formata, ESLint pega variáveis não usadas Java: Checkstyle + PMD + Spotless Kotlin: ktlint + Detekt Segredos em commit? GitLeaks e TruffleHog detectam antes do merge. Objetivo: remover ruído. Sobra atenção para o que importa. 18
19. Nível 2 — Segurança e integridade Barrar regressões graves antes de qualquer discussão subjetiva. TypeScript: CodeQL e Semgrep detectam injeção, eval() inseguro Java: SpotBugs identifica null pointers, resource leaks Kotlin/Spring: Trivy escaneia dependências com CVEs Branch protection, CODEOWNERS, checks obrigatórios de CI. Se dá para automatizar, não faz sentido desperdiçar atenção humana. 19
20. Nível 3 — Comportamento e contrato Testes e evidências. Automação forte, mas exige disciplina. React: Testing Library valida renderização e callbacks Java/Spring Boot: testes de integração com contexto Kotlin: MockK para contratos entre camadas Cross-stack: Pact para testes de contrato API Cobertura como proteção, não como métrica de vaidade. Pergunta:"essa mudança ainda faz o que deveria fazer?" 20
21. Nível 4 — Design e arquitetura Zona cinza. Ferramentas ajudam, mas não substituem julgamento. Java: ArchUnit detecta violação de fronteira arquitetural Kotlin: Service com 15 métodos públicos? Lint não pega. React: Componente de 400 linhas misturando tudo? Testes passam. useEffect com dependências erradas, N+1 queries, coroutines sem controle... Decisão final é humana. 21
22. Nível 5 — Produto, risco e estratégia A pergunta deixa de ser técnica e vira decisão de negócio. Isso resolve o problema certo? O risco operacional é aceitável? A mudança está alinhada à estratégia? O custo de manter compensa o ganho? Refatorar o código agora, quando o foco é reduzir churn? Endpoint novo expondo dados de usuário — risco regulatório avaliado? Automação apoia o contexto. Não decide prioridade. 22
23. Sim, vamos falar sobre IA Quando a pirâmide foi publicada, IA generativa não existia no fluxo. Hoje, agentes não só geram código — também revisam. A IA está subindo na pirâmide: Níveis 1-2: substitui trabalho humano com eficácia Nível 3: identifica testes ausentes, cenários de borda Nível 4: levanta sinais de acoplamento e complexidade Mas não com a precisão de um desenvolvedor experiente. 23
24. O limite da IA Com IA, o volume de alteração aumentou. Mais alterações por unidade de tempo. Às vezes, muito mais. Isso torna o papel humano mais importante. O agente acelera a execução. O humano é responsável pela direção, coerência e risco. A pirâmide continua válida — a fronteira entre automação e julgamento humano subiu alguns andares. E vai continuar subindo. 24
25. Boas práticas para review de verdade Separe blocos de tempo para revisar — fragmentado perde profundidade Evite PRs gigantes — diff maior = pior qualidade Leia o contexto antes do código — problema, decisão, impacto Faça duas passadas: 1. Entendimento global da mudança 2. Leitura detalhada por arquivo 25
26. Por onde começar 1. Nível 1 (estilo e formatação) — ganho imediato 2. Nível 2 (segurança) — redução de incidentes 3. Nível 3 (comportamento) — confiança para deploy 4. Níveis 4 e 5 — maturidade e cultura técnica Automatize tudo que é consenso mecânico. Preserve energia humana para contexto, risco e design. “ “ 26
27. Checklist por camada Camada O que verificar Base (automação) lint, format, SAST, segredos, dependências Comportamento testes relevantes, evidência de resultado Design fronteiras, acoplamento, legibilidade Negócio risco, rollout, observabilidade, rollback 27
28. Conclusão Code review não é carimbo para "liberar o merge". É conversa técnica sobre qualidade, risco e evolução. A pirâmide separa responsabilidades: Automação para o repetitivo, objetivo e escalável Julgamento humano para o contextual, ambíguo e estratégico A meta não é revisar mais PRs. É tomar melhores decisões de engenharia com menos ruído. “ “ 28
29. Referências principais Fagan (1976) — Design and Code Inspections Sadowski et al. (2018) — Modern Code Review at Google Bacchelli & Bird (2013) — Expectations of Modern Code Review Morling — The Code Review Pyramid Cohn (2009) — Test Pyramid 29
30. Obrigado! Artigo completo: notes.clementino.me Pirâmide original:Gunnar Morling 30