Thiago Julio

Desenvolvimento de software

PT EN

Code review num time pequeno: um padrão, um bot na primeira passada, uma pessoa no merge

code-review ia gitlab liderança

TL;DR - Nossos reviews ou eram carimbo ou eram uma semana de comentário sobre nome de variável. Escrevi um padrão de uma página, coloquei o PR-Agent no nosso GitLab self-hosted pra fazer a primeira passada e deixei a decisão do merge com uma pessoa. O bot pega o óbvio, e o review humano fica livre pra olhar regra de negócio e risco. Custa quase nada.

Quando comecei a liderar o time, o code review dependia de quem revisava. Alguns merge requests eram aprovados em dois minutos. Outros ficavam dias parados com comentário de estilo. Nenhum dos dois pegava os bugs que chegavam em produção. E cada vez mais código era escrito com IA, que parece limpo e falha nos cantos.

O padrão: uma página

Para quem abre o MR

  • MR pequeno. Diff grande recebe review raso.
  • Preencher o template: o que mudou, por quê, como testar e o que pode dar errado. O template fica no repo (.gitlab/merge_request_templates/), então o GitLab preenche sozinho.
  • Linkar o ticket.

Para quem revisa

  • Estilo é trabalho do linter. Se o linter não reclamou, eu também não reclamo.
  • Comportamento: faz o que o ticket pediu, e o que acontece com entrada ruim?
  • Testes: tem pelo menos um teste do caminho infeliz, com assert sobre regra de negócio?
  • Risco: migration, dependência nova, mudança em código compartilhado.

Todo comentário começa com o tipo: blocker:, suggestion:, question: ou nit:. Só blocker impede o merge. Só isso já acabou com muita discussão.

Código escrito por IA tem o mesmo review, com três checagens a mais

Código de IA costuma parecer bom. Formatação e nomes estão ok. O que falha está em outro lugar:

  • Casos de borda. Cobre o caminho feliz e esquece null, lista vazia e valor fora do intervalo.
  • Teste que espelha o código. A cobertura sobe e nada é garantido.
  • Dependência que ninguém pediu. Cada biblioteca nova é algo que o time vai ter que atualizar e debugar.

PR-Agent como primeiro revisor

Metade dos comentários humanos eram coisas que uma primeira passada cuidadosa pegaria. Configurei o PR-Agent no nosso GitLab self-hosted, usando um modelo da OpenAI. Ele roda quando um MR é aberto ou atualizado e comenta no próprio MR.

sequenceDiagram
  participant Dev as Dev
  participant GL as GitLab
  participant PA as PR-Agent
  participant Rev as Revisor
  Dev->>GL: Abre merge request
  GL->>PA: MR aberto ou atualizado
  PA->>GL: Descrição e primeira revisão
  Dev->>GL: Corrige ou responde
  Rev->>GL: Revisa comportamento, testes, risco
  Rev->>GL: Aprova e faz merge
  • /describe rascunha a descrição do MR a partir do diff. O autor edita, mas não começa do zero.
  • /review lista possíveis bugs, pontos de segurança e testes faltando.
  • /improve sugere mudanças no código. É o mais barulhento, então só roda quando alguém pede.

A conta foi uma surpresa boa: com o tamanho dos nossos MRs, o custo do modelo é quase zero.

Regras que mantive

  • O bot nunca aprova. Aprovar é trabalho e responsabilidade de uma pessoa.
  • Nada de secret ou dado de cliente no diff, com bot ou sem bot.
  • Se o bot errar, o autor responde “não se aplica” e segue. Ninguém discute com ele.

O que mudou

Os MRs ficaram menores, os reviews voltaram mais rápido, e os comentários humanos saíram de nome de variável para caso de borda e regra de negócio. O bot não substituiu o revisor. Ele levou a atenção do revisor para a parte que só uma pessoa consegue julgar.