A revisão de código pode ser melhor

• Muitos desenvolvedores estão insatisfeitos com a experiência de revisão de código no GitHub e vêm tentando novas abordagens para melhorá-la
• Uma ferramenta experimental chamada git-review foi projetada para tratar a revisão de código localmente, junto com o código, em vez de depender de uma interface web no navegador
• A revisão é gerenciada como um único commit, deixando comentários de revisão como anotações no código, e revisor e autor vão editando esse commit em conjunto
• No entanto, quando o código é alterado ou rebaseado durante a revisão, surgem incômodos com resolução de conflitos e uso de --force-with-lease, o que impediu maior adoção
• No fim, houve um retorno à revisão baseada na web, mas a ideia de incluir o estado da revisão diretamente no repositório continua atraente, e ainda há possibilidade de surgirem alternativas melhores com futuras melhorias no Git, como a adoção de um Change-Id no estilo Gerrit

---

Percepção dos problemas nos sistemas de revisão de código

• Atualmente, muita gente está insatisfeita com o processo de revisão de código do GitHub
• Os principais problemas incluem a falta de suporte para pull requests empilhados e revisão de interdiff, além de que
  • o estado da revisão não é armazenado dentro do repositório
  • a revisão exige uma interface web remota em primeiro lugar
• Os problemas que eu vejo são a falta de descentralização da revisão e a ineficiência da interface

Comparação entre fluxo de escrita de código e fluxo de revisão

• As pessoas escrevem código localmente usando um editor
  • É um ambiente com baixa latência de memória e NVMe, otimizado para o fluxo de trabalho particular de cada pessoa
• Também preferem revisar código fazendo pull da branch de origem localmente
  • Com ferramentas como Magit, é possível explorar não só o diff, mas também todo o contexto do código
  • Dá para aproveitar um ambiente de desenvolvimento poderoso, com execução de testes, navegação para definições, tentativas de refatoração etc.
• Em contrapartida, para deixar feedback em uma PR, é preciso ir para o navegador e usar uma interface web lenta, que em diffs grandes chega a ter atraso até na digitação

Interface e estrutura de armazenamento ideais para revisão de código

• Na prática, o mais natural é deixar comentários inline no código ou até editar o próprio código diretamente

  // CR(matklad): Hm, this check seems imprecise to me.  
  // Shouldn't we compare `replica.view` instead of `header.view` here?  
  if (header.view != view) return;  
  

• Quando os dados ficam em um banco de dados remoto, e não no repositório git local, também surgem problemas de latência e vendor lock-in

A ideia do git-review e a experiência prática

• A ideia do git-review é a seguinte:
  • a revisão de código acontece em um único commit no topo da branch da PR
  • nesse commit, são adicionados comentários no código com marcadores especiais
  • revisor e autor vão alternando edições nesse commit, colaborando com base em push --force-with-lease
  • quando todos os comentários são marcados como resolvidos (//? resolved), um commit de revert é adicionado ao final da revisão para preservar o registro
• A ideia é simples e prática, mas na realidade surgiram os seguintes problemas
  • quando o código é alterado durante a revisão, há conflitos frequentes entre os comentários e commits inferiores ou novos commits
  • o processo de force-push aumenta o atrito da colaboração e a complexidade do trabalho
  • fica difícil gerenciar a inconsistência entre o histórico de mudanças do código e o andamento da revisão, assim como os conflitos de merge

Novas mudanças e possibilidades futuras

• No futuro, pode haver adoção de um Change-Id no estilo Gerrit no Git upstream
  • Isso deve facilitar o rastreamento do histórico de alterações por commit e ampliar o suporte a revisão de interdiff
  • Mas há expectativa de alguns conflitos com a abordagem do git-review
  • Com a nova estrutura de Change-Id, talvez se tornem possíveis abordagens diferentes, como adicionar comentários de revisão ao próprio commit

Conclusão e apresentação de sistemas relevantes

• No momento, acabou havendo um retorno à revisão de código baseada em interface web
• A necessidade de uma solução melhor continua existindo
• Apresentação de sistemas e ferramentas relacionadas que valem a referência
  • Fossil: sistema de SCM que guarda todas as informações dentro do repositório
  • NoteDb: integra ao git o histórico de armazenamento do estado de revisão do Gerrit
  • git-bug: armazena informações de issues no git
  • git-appraise: mantém informações de revisão no próprio git
  • prr: implementa uma interface de revisão dentro do editor, integrada à API do GitHub
  • How Jane Street Does Code Review: apresenta um exemplo de uma realidade melhor
  • git-pr: projeto que substitui todo o fluxo de trabalho de PR por funcionalidades nativas do git

Encerramento

• Ainda não existe uma solução perfeita, e as tentativas por uma experiência melhor para desenvolvedores continuam
• Há grande expectativa em relação aos próximos avanços