💻 computer science

How Developers Use Relation Chains in Gerrit-Based Review Ecosystems: An Empirical Study Across Three Open-Source Ecosystems

Este estudo empírico de quase 30.000 cadeias de relação através de três ecossistemas baseados em Gerrit revela que, embora sequências de mudanças vinculadas por dependência sejam cada vez mais prevalentes, elas estendem significativamente os tempos de merge e propagam o esforço de revisão, necessitando que as futuras ferramentas e análises de revisão evoluam para raciocinar sobre essas cadeias estruturadas em vez de mudanças isoladas.

Autores originais: Ahmed Belhouchette, Moataz Chouchen, Marouene Chaieb, Mohammad Hamdaqa Abdelwahab Hamou-Lhadj

Publicado 2026-07-23

📖 7 min de leitura🧠 Leitura aprofundada

CC BY 4.0

Autores originais: Ahmed Belhouchette, Moataz Chouchen, Marouene Chaieb, Mohammad Hamdaqa Abdelwahab Hamou-Lhadj

Artigo original sob licença CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta é uma explicação gerada por IA do artigo abaixo. Não foi escrita nem endossada pelos autores. Para precisão técnica, consulte o artigo original. Ler aviso legal completo

Imagine um mundo onde construir software é como construir um castelo imenso e intrincado. Neste mundo, os desenvolvedores não apenas jogam tijolos contra uma parede e esperam que eles grudem; eles usam um sistema rigoroso chamado Revisão de Código (Code Review). Antes que qualquer novo tijolo (ou linha de código) seja adicionado permanentemente ao castelo, uma equipe de inspetores o verifica para procurar rachaduras, garante que ele se ajuste ao projeto e assegura que não quebre nada mais. Este processo é vital para manter o castelo erguido e seguro.

Às vezes, no entanto, um projeto é grande demais para ser um único tijolo. É uma torre inteira que precisa ser construída. No passado, os desenvolvedores poderiam ter tentado construir a torre inteira de uma vez, mas isso é difícil de inspecionar. Por isso, começaram a dividi-la em uma sequência de etapas menores e conectadas. No mundo do software, especificamente dentro de uma ferramenta chamada Gerrit, essas etapas conectadas são chamadas de Cadeias de Relação (Relation Chains). Pense em uma cadeia de relação como um conjunto de dominós parados em linha: embora você não possa derrubar o terceiro até que o segundo caia, e o segundo até que o primeiro caia, os inspetores podem verificar todos eles ao mesmo tempo, mas o castelo só pode ser concluído em ordem. Toda a cadeia está ligada; se o primeiro dominó (a "base") estiver instável, toda a linha estará em perigo. Entender como essas cadeias funcionam é crucial porque, se o sistema for muito lento ou confuso, os desenvolvedores podem ficar presos esperando por horas, ou o castelo pode ser construído com rachaduras ocultas.

O Efeito Dominó: Como os Desenvolvedores Realmente Usam Cadeias de Código

Este artigo é um mergulho profundo em como desenvolvedores de três enormes comunidades de código aberto (OpenStack, Wikimedia e ONAP) usam essas "Cadeias de Relação" para construir software. Os pesquisadores analisaram quase 30.000 cadeias e mais de 400.000 mudanças de código individuais para ver como esses dominós interligados se comportam no mundo real. Eles queriam saber: Essas cadeias são comuns? Elas tornam o processo de revisão mais rápido ou mais lento? E o que acontece quando você tenta consertar um dominó no meio da linha?

As Cadeias Estão em Todo Lugar (e Estão Crescendo)

Primeiro, o estudo descobriu que essas cadeias não são um truque raro ou de nicho; elas são uma forma padrão de trabalho. Dependendo do projeto, entre 5% e 49% de todas as mudanças de código fazem parte de uma cadeia. De fato, em 14 dos 15 projetos estudados, o uso dessas cadeias está, na verdade, aumentando com o tempo. Os desenvolvedores estão percebendo que dividir grandes tarefas em peças menores e interligadas é o caminho a seguir.

A maioria dessas cadeias é curta, geralmente um par de dominós (uma mudança base e uma mudança dependente). No entanto, alguns projetos têm cadeias que se estendem incrivelmente longe. Os pesquisadores encontraram cadeias com até 98 membros! Um projeto teve até uma única cadeia gerada automaticamente com quase 60.000 membros, embora esse fosse um caso especial de configuração automatizada, não escrita por humanos.

O "Meio" é o Gargalo

É aqui que fica interessante. Os pesquisadores descobriram que estar no meio de uma cadeia é o trabalho mais difícil. Se você é o primeiro dominó (a "base"), você apenas precisa esperar pela sua própria revisão. Se você é o último (o "topo"), você apenas espera pelos que vêm antes de você. Mas se você está no meio, você está preso em um aperto. Você é bloqueado pelo dominó antes de você (esperando pela aprovação dele) enquanto simultaneamente bloqueia os dominós depois de você.

Devido a esse "aperto", as mudanças no meio de uma cadeia levam significativamente mais tempo para serem aprovadas. O estudo descobriu que, em média, os membros da cadeia levam 2,6 vezes mais tempo para serem mesclados (merge) do que mudanças únicas e isoladas de mesmo tamanho. Esse atraso não é porque o código é pior; é por causa do "overhead de sincronização". Embora os inspetores (revisores) possam verificar os tijolos em paralelo, a mesclagem real no castelo deve acontecer um por um, de baixo para cima. Cada vez que uma mudança na cadeia é ajustada, ela frequentemente força toda a linha a ser re-verificada, re-testada e reordenada, criando um gargalo onde as mudanças do meio esperam pelas que estão abaixo delas enquanto também seguram as que estão acima.

O Monstro da "Amplificação de CI"

O artigo também destaca um fenôãmeno que eles chamam de efeito de amplificação de CI. "CI" significa Integração Contínua, que é como um exército de robôs que testa automaticamente cada novo tijolo para garantir que ele não quebre o castelo. Em projetos com regras estritas (como o OpenStack), toda vez que um desenvolvedor atualiza uma mudança em uma cadeia, o exército de robôs tem que re-testar essa mudança e todas as mudanças que dependem dela.

O estudo descobriu que os membros da cadeia disparam de 10 a 23 tarefas de teste automatizado, enquanto uma mudança única e isolada pode disparar menos de duas. É como se você tivesse que re-testar sua casa inteira toda vez que trocasse uma única lâmpada. Isso cria uma quantidade enorme de trabalho extra para os computadores e atrasos para os humanos.

O "Efeito Fundação"

Uma das descobertas mais fascinantes é o que os autores chamam de Efeito Fundação. Eles descobriram que a quantidade de esforço gasto no primeiro dominó (a base) prevê quanto esforço será gasto em todos os dominós seguintes.

Se a mudança base recebe muita atenção, muitos comentários e várias rodadas de revisão, toda a cadeia tende a seguir o mesmo padrão. Os pesquisadores encontraram uma forte ligação (uma correlação de 0,43 a 0,61) entre a atividade na base e a atividade nos descendentes. É como se a "vibe" do primeiro dominó definisse o tom para toda a linha. Se a fundação é instável e exige muitos reparos, a torre inteira leva mais tempo para ser construída. Por outro lado, se a base é sólida e é aprovada rapidamente, o resto da cadeia tende a fluir suavemente.

Cadeias Não São Estáticas

Finalmente, o artigo revela que essas cadeias não são estruturas rígidas. Cerca de 33,5% das mudanças em uma cadeia passam por uma "evolução estrutural" antes de serem finalmente mescladas. Isso significa que a conexão entre os dominós muda enquanto eles estão sendo revisados. Um desenvolvedor pode decidir desvincular uma mudança de seu pai e vinculá-la a um diferente, ou toda a cadeia pode ser reorganizada.

Isso adiciona outra camada de complexidade: o mapa da cadeia está constantemente mudando. Às vezes, uma cadeia pode ficar dormente por um longo tempo. O estudo descobriu que a lacuna entre quando uma parte de uma cadeia é enviada e quando ela finalmente é mesclada pode chegar a 2,85 anos em alguns casos!

O Que Isso Significa para o Futuro

Os autores concluem que as ferramentas atuais para revisar código frequentemente tratam cada mudança como um evento isolado, como olhar para um único tijolo sem ver a parede à qual ele pertence. Este artigo sugere que precisamos mudar nossas ferramentas para entender a "cadeia" como uma unidade completa.

Eles sugerem que, se focarmos nossa atenção na base da cadeia (o primeiro dominó), podemos economizar uma quantidade massiva de tempo para o restante da cadeia. Se a fundação for sólida, toda a estrutura se move mais rápido. Eles também propõem que as ferramentas devem ser mais inteligentes em relação às mudanças do "meio", talvez priorizando-as para desbloquear o restante da linha.

Em suma, construir software com cadeias de relação é como reger uma orquestra complexa. Se o regente (a base) estiver fora do ritmo, toda a orquestra sofre. Mas se o regente for claro e os músicos (as ferramentas) entenderem como os instrumentos estão ligados, a música flui muito mais rápido. O estudo sugere que, ao entender essas conexões, podemos parar de esperar na fila e começar a construir castelos de forma muito mais eficiente.

Resumo Técnico: Como Desenvolvedores Utilizam Cadeias de Relação em Ecossistemas de Revisão Baseados em Gerrit

Declaração do Problema
Os fluxos de trabalho de Revisão de Código Moderna (MCR) decompõem cada vez mais grandes tarefas de engenharia em sequências de mudanças dependentes, frequentemente submetidas como "mudanças empilhadas" (stacked changes). No ecossistema Gerrit, essas dependências formam cadeias de relação: unidades de revisão estruturadas onde o estado de uma revisão influencia diretamente a validação, sincronização e capacidade de mesclagem (mergeability) de revisões dependentes. Embora pesquisas empíricas anteriores tenham analisado extensivamente a revisão de código ao nível de mudanças isoladas (focando em latência, tamanho e participação de revisores), elas negligenciaram amplamente as cadeias de relação como artefatos de primeira classe. Estudos existentes ou modelam dependências de repositórios pareados, dependem de anotações textuais explícitas (ex: Depends-On), ou rastreiam referências de discussão, falhando em capturar os grafos de dependência estrutural que determinam a ordem de mesclagem e a dinâmica de coordenação inerente às cadeias. Consequentemente, as análises de revisão, ferramentas e sistemas assistidos por IA operam sob a premissão de que as mudanças são unidades independentes, potencialmente perdendo de vista custos de coordenação críticos e fatores estruturais que moldam os resultados das revisões.

Metodologia
Os autores conduziram um estudo empírico em três ecossistemas distintos baseados em Gerrit: OpenStack, Wikimedia e ONAP. O conjunto de dados compreende 401.256 mudanças revisadas e 29.580 cadeias de relação reconstruídas de 15 repositórios.

Extração de Dados: O estudo utilizou a API REST do Gerrit para extrair metadados de mudanças, revisões de patchset (incluindo SHAs de pais) e diffs de nível de arquivo, além de mensagens de revisão. As cadeias foram detectadas ao vincular mudanças onde o SHA pai de um patchset correspondia ao SHA da última revisão de outra mudança em revisão.
Métricas: O estudo computou métricas por mudança (revisões, rebases, duração da revisão, mensagens de discussão, comentários inline, tarefas de CI/CD) e métricas por cadeia (profundidade, lacunas de submissão, lacunas de mesclagem). As mudanças foram estratificadas por tamanho (XS a XL) para controlar variáveis de confusão.
Análise Estatística:
- RQ1 (Uso): Testes de tendência Mann–Kendall e a inclinação de Sen foram usados para analisar tendências de adoção temporal.
- RQ2 (Resultados): Testes Mann–Whitney U e o $\delta$ de Cliff foram empregados para comparar membros de cadeias contra mudanças "solo" de mesmo tamanho (mudanças sem um pai ou filho em revisão).
- RQ3 (Estrutura): Correlações de Spearman analisaram a relação entre a atividade da mudança base e a atividade média dos descendentes.
Escopo: A análise é observacional; os efeitos relatados são interpretados como associações, não como consequências causais.

Principais Contribuições e Resultados

1. Prevalência e Estrutura (RQ1)

Adoção: As cadeias de relação são prevalentes, variando de 5% a 49% das mudanças entre os projetos, com uma mediana de 17%. A adoção está aumentando em 14 dos 15 projetos estudados.
Profundidade: As cadeias são predominantemente rasas. A profundidade mediana é 2 (uma base e um descendente) em 12 de 15 projetos. Embora existam cadeias profundas (ex: um máximo de profundidade de 98 no ONAP sdc), elas são outliers raros.
Estabilidade: Apesar do aumento na adoção, a forma estrutural (profundidade) das cadeias permanece estável ao longo do tempo. Cadeias profundas geralmente correspondem a campanhas de engenharia coordenadas (ex: varreduras de refatoração) em vez de ruído.

2. Resultados da Revisão: Cadeia vs. Solo (RQ2)

Sobrecarga de Sincronização: Membros de cadeias levam um tempo mediano 2,6× maior para serem mesclados do que mudanças solo de mesmo tamanho. Essa sobrecarga é mais pronunciada para mudanças muito grandes (tamanho XL), onde o $\delta$ de Cliff atinge 0,49 (efeito grande).
Atividade de Revisão: Membros de cadeias não atraem mais mensagens de discussão de alto nível do que mudanças solo. No entanto, no OpenStack e Wikimedia, eles recebem significativamente mais comentários inline ancorados em código, sugerindo uma mudança na forma do feedback, e não no volume.
Amplificação de CI: Sob regimes de controle rigoroso de CI (ex: OpenStack), as cadeias de relação exibem um efeito de amplificação de CI. Membros da cadeia disparam 10–23 tarefas de CI/CD por posição, comparado a menos de duas para mudanças solo. Revisões em um membro reativam a validação em todos os descendentes dependentes.
Gargalos: Membros do meio da cadeia funcionam como gargalos de sincronização, absorvendo o maior esforço de revisão (revisões, rebases, duração) porque estão simultaneamente bloqueados por predecessores e bloqueando sucessores.

3. Fatores Estruturais Intra-Cadeia (RQ3)

O Controle de CI dita o Rendimento (Throughput): O tempo entre mesclagens (lacuna de mesclagem) é determinado pelo regime de controle de CI do projeto, não pela mecânica da cadeia. Projetos OpenStack exibem lacunas de mesclagem de 2 a 10 horas devido a pipelines de teste por membro, enquanto projetos Wikimedia e ONAP frequentemente mesclam em minutos assim que a base é aprovada.
O Efeito Fundação: Existe uma forte correlação positiva ( $\rho = 0,43–0,61$ ) entre a atividade de revisão da mudança base e a atividade média de seus descendentes. Cadeias com bases de alto esforço resultam consistentemente em descendentes de alto esforço, sugerindo que o esforço de revisão se propaga através do grafo de dependência.
Reestruturação Dinâmica: As cadeias não são estáticas. 33,5% dos membros de cadeia passam por uma mudança estrutural em seu SHA pai antes da mesclagem (ex: desprendendo-se de um pai em revisão), ocorrendo frequentemente durante a revisão.
Longevidade: As cadeias podem persistir por períodos de vários anos, com lacunas de mesclagem atingindo até 2,85 anos em alguns casos.

Significância e Alegações
O artigo argumenta que as cadeias de relação são unidades de coordenação duráveis e moldadas pelo ecossistema com estruturas internas que análises centradas em mudanças individuais não conseguem capturar. Os autores alegam que:

As Ferramentas Atuais estão Desalinhadas: As ferramentas de revisão padrão, que processam mudanças de forma independente, falham em considerar a sobrecarga de sincronização, a amplificação de CI e as dinâmicas estruturais das cadeias.
Modelos Preditivos são Incompletos: Modelos que preveem latência ou esforço de revisão baseados apenas em características de nível de mudança omitem sinais críticos de nível de cadeia (posição, atividade da base, evolução da dependência) que correlacionam com os resultados.
Intervenção Estratégica: O "Efeito Fundação" sugere um ponto de intervenção de alto impacto: concentrar a atenção da revisão na mudança base pode propagar benefícios (redução de fricção) por toda a cadeia.
Direções Futuras: Os autores defendem a necessidade de análises de revisão conscientes de cadeias (chain-aware), sistemas de atribuição de revisores que priorizem mudanças que desbloqueiam o maior subgrafo a jusante, e agentes de revisão assistidos por IA que condicionem sua atuação à posição na cadeia e ao estado da mudança base.

O estudo conclui que compreender essas estruturas de dependência é essencial para análises de revisão precisas e para o desenvolvimento de ferramentas eficazes em modernos ecossistemas de engenharia de software de larga escala.