Como a Meta melhorou o seu tempo de revisão de código
A Meta estudou diversas métricas para entender melhor os gargalos do code review e, com isso, encontrou uma correlação entre os tempos lentos de revisão de código (P75 — as revisões que estão dentre as 25% mais lentas) e a insatisfação do engenheiro. As ferramentas para apresentar diferenças aos revisores certos em momentos-chave no ciclo de vida da revisão de código melhoraram significativamente a experiência de revisão de diffs.
OBS: Na Meta, um conjunto individual de alterações feitas na base de código é chamado de "diff", então eu acredito que um PR seja chamado de diff, pois é um conjunto de mudanças com o mesmo "tema".
O que faz a revisão ser lenta
A Meta rastreia uma métrica que chama de "Tempo na revisão", que é uma medida de quanto tempo um diff está aguardando revisão em todos os seus ciclos de revisão individuais. É contabilizado apenas o tempo em que o diff está aguardando a ação do revisor, como requerir mudanças ou aceitá-las.
Ao analisar os dados no início de 2021, a média (P50) de horas em análise para uma diferença era de apenas algumas horas, o que parecia muito bom. No entanto, olhando para P75, o tempo de revisão aumentou em até um dia. A métrica norte, então, era o tempo na revisão do P75.
O objetivo em diminuir o tempo de revisão não era apenas deixar as pessoas mais satisfeitas com o processo de revisão de código, mas também aumentar a produtividade de todos os engenheiros da Meta.
Próxima diff revisável
A Meta criou uma funcionalidade que leva o revisador para o próximo diff revisável, isso significa:
- Estimular um estado de fluxo (flow state);
- Usar melhor o tempo e a energia dos revisadores;
- Evitar mudança de contexto entre as revisões.
O aprendizado de máquina foi utilizado para identificar um diff que o revisor atual provavelmente deseja revisar. Depois que o revisor termina a revisão de código atual, esse diff é mostrado para ele. Ficou mais fácil percorrer os possíveis próximos diffs e o revisor é removido se um diff não for relevante para ele.
Após o lançamento, esse recurso resultou em um aumento geral de 17% nas ações de revisão por dia (como aceitar uma diferença, comentar etc.) e os engenheiros que usam esse fluxo executam 44% mais ações de revisão do que o revisor médio.
Melhorando as recomendações do revisor
A Meta construiu um novo sistema de recomendação de revisores, incorporando informações sobre horário de trabalho e propriedade de arquivos. Isso permite que os revisores que estão disponíveis para revisar um diff e têm maior probabilidade de serem ótimos revisores sejam priorizados.
Houve um aumento de 1,5% nas diferenças revisadas em 24 horas e um aumento na precisão das três principais recomendações (com que frequência o revisor real é um dos três principais sugeridos) de menos de 60% para quase 75%. O novo modelo também foi 14 vezes mais rápido (latência P90).
Robô de diffs stale (velhas)
Para diferenças que estavam demorando muito para serem revisadas, o robô Nudgebot determina o subconjunto de revisores com maior probabilidade de revisar as diferenças. Em seguida, ele envia a eles um ping no chat com o contexto apropriado para a diferença, juntamente com um conjunto de ações rápidas que permitem que os destinatários pulem direto para a revisão.
O tempo médio em revisão para todas as diferenças caiu 7% (ajustado para excluir fins de semana) e a proporção de diferenças que esperaram mais de três dias para revisão caiu 12%.
O que vem a seguir para a Meta?
A Meta pretende continuar a melhorar o processo de revisão de código respondendo as seguintes perguntas:
- Qual é o conjunto certo de pessoas para revisar uma determinada diferença?
- Como podemos tornar mais fácil para os revisores terem as informações de que precisam para fazer uma avaliação de alta qualidade?
- Como podemos aproveitar a IA e o aprendizado de máquina para melhorar o processo de revisão de código?
Discussão relacionada
Semana passada teve uma publicação aqui no TabNews muito legal, uma discussão sobre Mergear um código sem revisão é uma boa ?. Para a Meta, isso é importante, e por isso se esforçaram tanto em melhorar essa parte do dia do desenvolvedor.