O objetivo principal da revisão de código é encontrar código que será difícil de manter

Artigo original ↗ Discussão no Hacker News ↗

Objetivo da revisão de código: metas únicas vs múltiplas

  • Muitos discordam de enquadrar “encontrar código difícil de manter” como o principal objetivo.
  • Alternativas propostas como principais: transferência de conhecimento, correção/redução de bugs, verificações de sanidade do design, segurança ou simplesmente “ter uma conversa sobre a mudança”.
  • Vários argumentam que não existe um único propósito; a revisão de código é inerentemente multipropósito e depende do contexto (tamanho da equipe, nível de confiança, domínio, regulamentação).

Manutenibilidade vs detecção de bugs

  • Alguns apoiam o enquadramento de priorizar a manutenibilidade: se o código é claro e simples, bugs são mais fáceis de identificar e as correções são mais seguras.
  • Outros enfatizam que eles encontram bugs reais rotineiramente na revisão (erros de lógica, casos de borda, problemas de segurança e desempenho) e veem isso como central, não incidental.
  • Vários comentários rebatem a ideia de que examinar código “não pode” encontrar bugs, chamando isso de incorreto na prática ou de uma afirmação teórica mal comunicada.

Compartilhamento de conhecimento e ownership

  • Tema recorrente forte: revisão de código como transferência de conhecimento e ownership compartilhado.
  • Ler PRs mantém os colegas cientes das mudanças no sistema, evita surpresas e aumenta o “bus factor”.
  • Algumas equipes até criam PRs puramente como artefato de comunicação, mesmo quando fazem merge imediatamente.

Processo, fluxo de trabalho e cultura

  • As visões divergem fortemente conforme o fluxo de trabalho:
    • Processos estruturados, com design antes do código vs “fazer o design no PR”.
    • Equipes pequenas, com alta confiança vs ambientes grandes, com baixa confiança ou regulados.
    • Revisões assíncronas no estilo GitHub vs revisões síncronas, em formato de reunião.
  • A revisão de código pode ser saudável (ensino, colaboração) ou tóxica (controle de acesso, disputas de status, aprovações performáticas). A cultura da equipe e a orientação são vistas como cruciais.

Testes vs revisão

  • Muitos enfatizam que são os testes, e não a revisão, que devem fornecer as principais garantias de correção.
  • Boas revisões também verificam a existência e a qualidade dos testes ou dos planos de teste.
  • Alguns observam que a revisão às vezes detecta problemas de integração que os testes podem não capturar, especialmente quando a documentação e as fronteiras do sistema são fracas.

IA e o cenário em mudança

  • Vários apontam que código gerado por IA e revisões assistidas por IA aumentam o volume e o “slop”, tornando a revisão humana cuidadosa mais difícil.
  • Alguns preveem que as revisões de PR se tornarão insustentáveis ou serão transformadas; outros insistem que humanos ainda precisam garantir o entendimento e a manutenibilidade do código escrito por IA.