Critique - como o Google reduz a dor do code review com 97% de satisfação dos desenvolvedores

xguru · 2023-12-11T10:32:02+09:00

Muitos ex-Googlers sentem falta da ferramenta de code review do Google, "Critique" Segundo uma pesquisa interna do Google, 97% dos desenvolvedores estão satisfeitos com o Critique Diretrizes de code review do Google Incentivar melhoria contínua em vez de perfeição Manter ou melhorar o estado da codebase Seguir o guia de estilo Sempre compartilhar conhecimento: incentivar o compartilhamento de conhecimento sobre recursos da linguagem, a codebase e outros artefatos relevantes por meio do code review Escrever mudanças pequenas (cerca de 200 linhas) Critérios rigorosos para leveza no processo (revisar mudanças de código em até 24 horas, de preferência com um único revisor) Educação e profissionalismo: é importante manter uma cultura de confiança e respeito Critique: a ferramenta de code review do Google Permite que engenheiros revisem mudanças de código com eficiência e façam o envio para submissão Segundo o artigo recente - Resolving code review comments with ML, o Google usa uma ferramenta abrangente de code review baseada em AI Quando o revisor deixa um comentário no código, o Critique mostra sugestões de edição baseadas em ML O autor do code review pode corrigir aquele comentário por completo com apenas um clique em um botão Fluxo de code review Etapa 1: escrever a mudança O CL (ou Pull Request) é criado no editor de código interno do Google, o Cider Ele é integrado de forma estreita ao Critique e a outras ferramentas internas do Google para aumentar a produtividade dos desenvolvedores Ferramenta Prereview: refina as mudanças antes da revisão e mostra diferenças, resultados de build e de testes, além de verificações de estilo Visualização e análise de Diff: destaque de sintaxe, referências cruzadas, intraline diffing, ignorar espaços em branco e detecção de movimentação Mostra os resultados de analisadores estáticos para destacar achados importantes e oferecer sugestões de correção. Inclui os "presubmits", testes automatizados executados dentro do Critique Etapa 2: solicitar revisão Quando o Pull Request está pronto para revisão, o autor do código adiciona revisores e o envia formalmente para revisão Quando o PR/CL é enviado para revisão, os "Presubmits" são executados se ainda não estiverem presentes no snapshot atual do código. Assim, todos os participantes da revisão podem saber se há problemas no código Também é possível anonimizar o code review para manter o autor do código anônimo diante dos revisores. No entanto, o Google não encontrou diferenças úteis entre code review anônimo e code review "real" Etapas 3 e 4: entender a mudança e comentar Qualquer pessoa pode comentar na mudança, e há recursos para acompanhar o andamento da revisão e resolver comentários Comentários não resolvidos representam itens de ação que o autor da mudança precisa resolver com certeza. Esses comentários podem ser marcados como "resolvidos" quando o autor do código responde diretamente ao comentário Comentários resolvidos incluem observações opcionais ou informativas que podem não exigir ação do autor da mudança Há um dashboard para verificar o estado da revisão e um "Attention Set" para que as pessoas envolvidas em uma revisão específica saibam quem está aguardando no momento Etapa 5: aprovar a mudança Como mencionado acima, para que a revisão seja registrada, é preciso receber pelo menos um LGTM (Looks Good To Me) de um revisor O autor do código pode marcar diretamente comentários como resolvidos ao comentar, mas é necessário que o número de comentários não resolvidos seja 0 Também é necessário ter aprovação do responsável pela parte da codebase onde o código entra, além da aprovação de legibilidade Tudo isso pode ser feito por um único revisor Etapa 6: fazer commit da mudança A mudança é submetida e comitada dentro do próprio Critique O Critique continua sendo útil mesmo depois que a mudança é submetida "Pesquisadores do Google encontraram fortes evidências de que o uso do Critique vai além da revisão de código. Autores de mudanças usam o Critique para revisar Diffs e consultar resultados de ferramentas de análise. Em alguns casos, o code review faz parte do processo de desenvolvimento da mudança, e revisores podem receber mudanças inacabadas para decidir como concluir a implementação. Além disso, desenvolvedores usam o Critique para revisar o histórico de mudanças submetidas mesmo depois que elas são aprovadas." Estatísticas mais recentes de code review no Google Frequência de criação de mudanças: Mediana: 3 mudanças por semana 80% dos autores fazem menos de 7 mudanças por semana Frequência de revisão: Mediana: revisar 4 mudanças por semana 80% dos revisores lidam com menos de 10 mudanças por semana Tempo gasto por semana em revisões: Média de 3,2 horas por semana Mediana de 2,6 horas por semana Tempo de espera para o feedback inicial: Mudanças pequenas: menos de 1 hora em média Mudanças muito grandes: cerca de 5 horas Tempo total do processo de revisão: Latência média para todos os tamanhos de código: menos de 4 horas Comparação com outras empresas: AMD: 17,5 horas (mediana até aprovação) Chrome OS: 15,7 horas Projetos da Microsoft: 14,7 horas, 19,8 horas, 18,9 horas Microsoft (outro estudo): 24 horas Por que os Googlers adoram o Critique? Análise estática: possui um conjunto completo de ferramentas de análise estática que fornecem automaticamente feedback acionável sobre o código. Isso economiza tempo tanto para o autor quanto para o revisor, e o revisor não precisa apontar manualmente o óbvio Foco apenas nos arquivos alterados mais recentemente: é possível se concentrar apenas no "snapshot" mais recente do código. Snapshots anteriores, commits e mudanças de código não são exibidos, deixando a interface mais limpa Interface familiar de Diff lado a lado: por padrão, mostra as "diferenças desde a última revisão" Sugestões baseadas em machine learning: o novo recurso de sugestões baseadas em ML do Google acelera muito o code review Integração estreita com outras ferramentas do Google: o Critique se integra muito bem com outras ferramentas internas do Google, como IDEs e rastreadores de bugs, aumentando a produtividade. Isso inclui ligação fácil entre código, comentários e tickets Rastreamento de "conjunto de trabalho": permite saber quem precisa agir em seguida Gamificação satisfatória: embora o Critique não tenha sido projetado para ser gamificado, os Googlers dizem que era prazeroso quando o Critique "ficava verde" e o PR estava pronto para submissão (todos os testes passando, aprovação LGTM dos revisores) Comentários do Reddit Atalhos de teclado incríveis que permitem revisar uma enorme quantidade de código com muita eficiência Por padrão, mostra "o que mudou desde a última revisão" O recurso de "detecção de movimentação de código" permite focar nas mudanças reais do código Oferece um recurso excelente para indicar quem precisa tomar ação, seja revisor ou autor Com a extensão do Chrome, é fácil receber notificações e verificar a fila de revisões Internamente, qualquer pessoa pode fazer queries nos dados de code review para coletar insights Vinculação automática entre código e comentários (incluindo tickets e mover/linkar) É muito mais fácil entender o progresso de PRs com várias rodadas de código, pois é possível ver em forma de tabela a análise, o histórico e os comentários do PR A terminologia/tags dos comentários, como opcional, observação etc., é muito consistente Reflexões e implicações Muitos desses recursos já existem em outras ferramentas hoje, mas acredito que a razão de essa ferramenta ser tão amada está na integração estreita e na extrema "personalização" para o workflow e a codebase específicos do Google Ao mesmo tempo, isso também significa que é praticamente impossível para toda empresa replicar exatamente o Critique e as ferramentas relacionadas. Por exemplo, algumas ferramentas são especializadas em problemas que surgem por causa de uma estrutura de monorepo O próprio Critique provavelmente não será disponibilizado como open source, mas o Gerrit é uma ferramenta parecida com o Critique. Também é uma ferramenta open source de revisão de código criada e mantida pelo Google Ainda assim, acho que o Google dedica muito esforço e reflexão à produtividade dos desenvolvedores. Eles publicam livremente suas pesquisas, e é possível tirar implicações úteis desse trabalho

(engineercodex.substack.com)

52 pontos por xguru 2023-12-11 | 5 comentários | Compartilhar no WhatsApp

Muitos ex-Googlers sentem falta da ferramenta de code review do Google, "Critique"
Segundo uma pesquisa interna do Google, 97% dos desenvolvedores estão satisfeitos com o Critique

Diretrizes de code review do Google

Incentivar melhoria contínua em vez de perfeição
Manter ou melhorar o estado da codebase
Seguir o guia de estilo
Sempre compartilhar conhecimento: incentivar o compartilhamento de conhecimento sobre recursos da linguagem, a codebase e outros artefatos relevantes por meio do code review
Escrever mudanças pequenas (cerca de 200 linhas)
Critérios rigorosos para leveza no processo (revisar mudanças de código em até 24 horas, de preferência com um único revisor)
Educação e profissionalismo: é importante manter uma cultura de confiança e respeito

Critique: a ferramenta de code review do Google

Permite que engenheiros revisem mudanças de código com eficiência e façam o envio para submissão
Segundo o artigo recente - Resolving code review comments with ML, o Google usa uma ferramenta abrangente de code review baseada em AI
- Quando o revisor deixa um comentário no código, o Critique mostra sugestões de edição baseadas em ML
- O autor do code review pode corrigir aquele comentário por completo com apenas um clique em um botão

Fluxo de code review

Etapa 1: escrever a mudança
- O CL (ou Pull Request) é criado no editor de código interno do Google, o Cider
- Ele é integrado de forma estreita ao Critique e a outras ferramentas internas do Google para aumentar a produtividade dos desenvolvedores
- Ferramenta Prereview: refina as mudanças antes da revisão e mostra diferenças, resultados de build e de testes, além de verificações de estilo
- Visualização e análise de Diff: destaque de sintaxe, referências cruzadas, intraline diffing, ignorar espaços em branco e detecção de movimentação
- Mostra os resultados de analisadores estáticos para destacar achados importantes e oferecer sugestões de correção. Inclui os "presubmits", testes automatizados executados dentro do Critique
Etapa 2: solicitar revisão
- Quando o Pull Request está pronto para revisão, o autor do código adiciona revisores e o envia formalmente para revisão
- Quando o PR/CL é enviado para revisão, os "Presubmits" são executados se ainda não estiverem presentes no snapshot atual do código. Assim, todos os participantes da revisão podem saber se há problemas no código
- Também é possível anonimizar o code review para manter o autor do código anônimo diante dos revisores. No entanto, o Google não encontrou diferenças úteis entre code review anônimo e code review "real"
Etapas 3 e 4: entender a mudança e comentar
- Qualquer pessoa pode comentar na mudança, e há recursos para acompanhar o andamento da revisão e resolver comentários
- Comentários não resolvidos representam itens de ação que o autor da mudança precisa resolver com certeza. Esses comentários podem ser marcados como "resolvidos" quando o autor do código responde diretamente ao comentário
- Comentários resolvidos incluem observações opcionais ou informativas que podem não exigir ação do autor da mudança
- Há um dashboard para verificar o estado da revisão e um "Attention Set" para que as pessoas envolvidas em uma revisão específica saibam quem está aguardando no momento
Etapa 5: aprovar a mudança
- Como mencionado acima, para que a revisão seja registrada, é preciso receber pelo menos um LGTM (Looks Good To Me) de um revisor
- O autor do código pode marcar diretamente comentários como resolvidos ao comentar, mas é necessário que o número de comentários não resolvidos seja 0
- Também é necessário ter aprovação do responsável pela parte da codebase onde o código entra, além da aprovação de legibilidade
- Tudo isso pode ser feito por um único revisor
Etapa 6: fazer commit da mudança
- A mudança é submetida e comitada dentro do próprio Critique
- O Critique continua sendo útil mesmo depois que a mudança é submetida
- "Pesquisadores do Google encontraram fortes evidências de que o uso do Critique vai além da revisão de código. Autores de mudanças usam o Critique para revisar Diffs e consultar resultados de ferramentas de análise. Em alguns casos, o code review faz parte do processo de desenvolvimento da mudança, e revisores podem receber mudanças inacabadas para decidir como concluir a implementação. Além disso, desenvolvedores usam o Critique para revisar o histórico de mudanças submetidas mesmo depois que elas são aprovadas."

Estatísticas mais recentes de code review no Google

Frequência de criação de mudanças:
- Mediana: 3 mudanças por semana
- 80% dos autores fazem menos de 7 mudanças por semana
Frequência de revisão:
- Mediana: revisar 4 mudanças por semana
- 80% dos revisores lidam com menos de 10 mudanças por semana
Tempo gasto por semana em revisões:
- Média de 3,2 horas por semana
- Mediana de 2,6 horas por semana
Tempo de espera para o feedback inicial:
- Mudanças pequenas: menos de 1 hora em média
- Mudanças muito grandes: cerca de 5 horas
Tempo total do processo de revisão:
- Latência média para todos os tamanhos de código: menos de 4 horas
- Comparação com outras empresas:
  - AMD: 17,5 horas (mediana até aprovação)
  - Chrome OS: 15,7 horas
  - Projetos da Microsoft: 14,7 horas, 19,8 horas, 18,9 horas
  - Microsoft (outro estudo): 24 horas

Por que os Googlers adoram o Critique?

Análise estática: possui um conjunto completo de ferramentas de análise estática que fornecem automaticamente feedback acionável sobre o código. Isso economiza tempo tanto para o autor quanto para o revisor, e o revisor não precisa apontar manualmente o óbvio
Foco apenas nos arquivos alterados mais recentemente: é possível se concentrar apenas no "snapshot" mais recente do código. Snapshots anteriores, commits e mudanças de código não são exibidos, deixando a interface mais limpa
Interface familiar de Diff lado a lado: por padrão, mostra as "diferenças desde a última revisão"
Sugestões baseadas em machine learning: o novo recurso de sugestões baseadas em ML do Google acelera muito o code review
Integração estreita com outras ferramentas do Google: o Critique se integra muito bem com outras ferramentas internas do Google, como IDEs e rastreadores de bugs, aumentando a produtividade. Isso inclui ligação fácil entre código, comentários e tickets
Rastreamento de "conjunto de trabalho": permite saber quem precisa agir em seguida
Gamificação satisfatória: embora o Critique não tenha sido projetado para ser gamificado, os Googlers dizem que era prazeroso quando o Critique "ficava verde" e o PR estava pronto para submissão (todos os testes passando, aprovação LGTM dos revisores)
Comentários do Reddit
- Atalhos de teclado incríveis que permitem revisar uma enorme quantidade de código com muita eficiência
- Por padrão, mostra "o que mudou desde a última revisão"
- O recurso de "detecção de movimentação de código" permite focar nas mudanças reais do código
- Oferece um recurso excelente para indicar quem precisa tomar ação, seja revisor ou autor
- Com a extensão do Chrome, é fácil receber notificações e verificar a fila de revisões
- Internamente, qualquer pessoa pode fazer queries nos dados de code review para coletar insights
- Vinculação automática entre código e comentários (incluindo tickets e mover/linkar)
- É muito mais fácil entender o progresso de PRs com várias rodadas de código, pois é possível ver em forma de tabela a análise, o histórico e os comentários do PR
- A terminologia/tags dos comentários, como opcional, observação etc., é muito consistente

Reflexões e implicações

Muitos desses recursos já existem em outras ferramentas hoje, mas acredito que a razão de essa ferramenta ser tão amada está na integração estreita e na extrema "personalização" para o workflow e a codebase específicos do Google
Ao mesmo tempo, isso também significa que é praticamente impossível para toda empresa replicar exatamente o Critique e as ferramentas relacionadas. Por exemplo, algumas ferramentas são especializadas em problemas que surgem por causa de uma estrutura de monorepo
O próprio Critique provavelmente não será disponibilizado como open source, mas o Gerrit é uma ferramenta parecida com o Critique. Também é uma ferramenta open source de revisão de código criada e mantida pelo Google
Ainda assim, acho que o Google dedica muito esforço e reflexão à produtividade dos desenvolvedores. Eles publicam livremente suas pesquisas, e é possível tirar implicações úteis desse trabalho

5 comentários

xguru 2023-12-17

Parece que existem algumas tentativas de integrar o ChatGPT ao Gerrit
https://github.com/xielong/chatgpt-code-review-gerrit-plugin

kkweon 2023-12-12

O ponto que mais se destaca para mim é que, no Critique, dá para revisar uma série de CLs consecutivos. No GitHub, é incômodo que não haja suporte direto a cadeias de PRs. Por isso, acaba virando um único PR grande, ou então é preciso esperar até que o PR anterior seja mesclado.

tested 2023-12-11

O GitHub também tem algo parecido; resta saber quando vai abrir. > https://githubnext.com/projects/copilot-for-pull-requests

winterjung 2023-12-11

Não há análise estática nem sugestões baseadas em ML, mas pelo texto parece bem parecido com o recurso de review do GitHub. Como alguém que usa bastante o review do GitHub, seria ótimo se mais recursos diferentes oferecidos pelo Critique também fossem adotados.

xguru 2023-12-11

Guia de code review do Google [tradução para coreano]