💻 computer science

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

Questo studio empirico di quasi 30.000 catene di relazioni attraverso tre ecosistemi basati su Gerrit rivela che, sebbene le sequenze di modifiche collegate da dipendenze siano sempre più prevalenti, esse estendono significativamente i tempi di merge e propagano lo sforzo di revisione, rendendo necessario che i futuri strumenti e analisi di revisione evolvano per ragionare su queste catene strutturate piuttosto che su modifiche isolate.

Autori originali: Ahmed Belhouchette, Moataz Chouchen, Marouene Chaieb, Mohammad Hamdaqa Abdelwahab Hamou-Lhadj

Pubblicato 2026-07-23

📖 7 min di lettura🧠 Approfondimento

CC BY 4.0

Autori originali: Ahmed Belhouchette, Moataz Chouchen, Marouene Chaieb, Mohammad Hamdaqa Abdelwahab Hamou-Lhadj

Articolo originale sotto licenza CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Questa è una spiegazione generata dall'IA dell'articolo qui sotto. Non è stata scritta né approvata dagli autori. Per precisione tecnica, consulta l'articolo originale. Leggi il disclaimer completo

Immaginate un mondo in cui costruire software è come costruire un castello massiccio e intricato. In questo mondo, gli sviluppatori non si limitano a lanciare mattoni contro un muro sperando che si attacchino; usano un sistema rigoroso chiamato Code Review (Revisione del Codice). Prima che ogni nuovo mattone (o riga di codice) venga aggiunto permanentemente al castello, un team di ispettori lo controlla per verificare la presenza di crepe, assicura che si adatti al progetto e si assicura che non rompa nient'altro. Questo processo è vitale per mantenere il castello alto e sicuro.

A volte, tuttavia, un progetto è troppo grande per essere un singolo mattone. È un'intera torre che deve essere costruita. In passato, gli sviluppatori avrebbero potuto cercare di costruire l'intera torre in una volta sola, ma questo è difficile da ispezionare. Così, hanno iniziato a scomporla in una sequenza di passi più piccoli e connessi. Nel mondo del software, specificamente all'interno di uno strumento chiamato Gerrit, questi passi connessi sono chiamati Relation Chains (Catene di Relazione). Pensate a una catena di relazione come a un set di domino in piedi in linea: sebbene non si possa abbattere il terzo domino finché il secondo non cade, e il secondo finché il primo non cade, gli ispettori possono controllare tutti loro contemporaneamente, ma il castello può essere completato solo in ordine. L'intera catena è collegata; se il primo domino (la "base") è traballante, l'intera linea è nei guai. Comprendere come funzionano queste catene è cruciale perché, se il sistema è troppo lento o confuso, gli sviluppatori potrebbero rimanere bloccati per ore, o il castello potrebbe essere costruito con crepe nascoste.

L'Effetto Domino: Come gli Sviluppatori Usano Effettivamente le Catene di Codice

Questo articolo è un'analisi approfondita di come gli sviluppatori in tre enormi comunità open-source (OpenStack, Wikimedia e ONAP) utilizzano queste "Relation Chains" per costruire software. I ricercatori hanno esaminato quasi 30.000 catene e oltre 400.000 singole modifiche al codice per vedere come questi domino collegati si comportano nel mondo reale. Volevano sapere: Queste catene sono comuni? Rendono il processo di revisione più veloce o più lento? E cosa succede quando si prova a riparare un domino nel mezzo della linea?

Le Catene Sono Ovunque (e Stanno Crescendo)

In primo luogo, lo studio ha scoperto che queste catene non sono un trucco raro e di nicchia; sono un modo standard di lavorare. A seconda del progetto, tra il 5% e il 49% di tutte le modifiche al codice fa parte di una catena. Infatti, in 14 dei 15 progetti studiati, l'uso di queste catene è in realtà in aumento nel tempo. Gli sviluppatori si stanno rendendo conto che scomporre i grandi compiti in pezzi più piccoli e collegati è la strada da seguire.

La maggior parte di queste catene è breve, solitamente solo una coppia di domino (una modifica base e una modifica dipendente). Tuttavia, alcuni progetti hanno catene che si estendono incredibilmente in profondità. I ricercatori hanno trovato catene con fino a 98 membri! Un progetto ha persino avuto una singola catena auto-generata con quasi 60.000 membri, sebbene questo fosse un caso speciale di configurazione automatizzata, non di scrittura umana.

Il "Centro" è il Collo di Bottiglia

Ecco dove la questione si fa interessante. I ricercatori hanno scoperto che stare nel mezzo di una catena è il lavoro più difficile. Se sei il primo domino (la "base"), devi solo aspettare la tua revisione. Se sei l'ultimo (il "top"), devi solo aspettare quelli che ti precedono. Ma se sei nel mezzo, sei intrappolato in una morsa. Sei bloccato dal domino prima di te (in attesa della sua approvazione) mentre simultaneamente blocchi i domino dopo di te.

A causa di questa "morsa", le modifiche nel mezzo di una catena impiegano significativamente più tempo per essere approvate. Lo studio ha scoperto che, in media, i membri di una catena impiegano 2,6 volte più tempo per essere uniti (merge) rispetto a modifiche singole e isolate della stessa dimensione. Questo ritardo non è dovuto al fatto che il codice sia peggiore; è dovuto all' "overhead di sincronizzazione". Anche se gli ispettori (reviewer) possono controllare i mattoni in parallelo, l'unione effettiva nel castello deve avvenire uno alla volta, dal basso verso l'alto. Ogni volta che una modifica nella catena viene ritoccata, spesso costringe l'intera linea a essere ricontrollata, ricontrollata e riordinata, creando un collo di bottiglia dove le modifiche centrali aspettano quelle sottostanti mentre bloccano anche quelle superiori.

Il Mostro dell' "Amplificazione CI"

Il documento evidenzia anche un fenomeno che chiamano effetto amplificazione CI. "CI" sta per Integrazione Continua (Continuous Integration), che è come un esercito di robot che testa automaticamente ogni nuovo mattone per assicurarsi che non rompa il castello. In progetti con regole rigide (come OpenStack), ogni volta che uno sviluppatore aggiorna una modifica in una catena, l'esercito di robot deve ri-testare quella modifica e tutte le modifiche che dipendono da essa.

Lo studio ha scoperto che i membri della catena attivano da 10 a 23 lavori di test automatizzati, mentre una modifica singola e isolata potrebbe attivare meno di due lavori. È come se dovessi ri-testare l'intera casa ogni volta che cambi una singola lampadina. Questo crea una quantità enorme di lavoro extra per i computer e ritardi per gli esseri umani.

L' "Effetto Fondamenta"

Una delle scoperte più affascinanti è quella che gli autori chiamano l' Effetto Fondamenta (Foundation Effect). Hanno scoperto che la quantità di sforzo speso sulla prima domino (la base) predice quanto sforzo sarà speso su tutti i domino successivi.

Se la modifica base riceve molta attenzione, molti commenti e molti round di revisione, l'intera catena tende a seguire l'esempio. I ricercatori hanno trovato un forte legame (una correlazione di 0,43 - 0,61) tra l'attività sulla base e l'attività sui discendenti. È come se l' "atmosfera" del primo domino dettasse il tono per l'intera linea. Se la fondazione è traballante e richiede molte riparazioni, l'intera torre impiega più tempo per essere costruita. Al contrario, se la base è solida e viene approvata rapidamente, il resto della catena tende a fluire senza intoppi.

Le Catene Non Sono Statiche

Infine, il documento rivela che queste catene non sono strutture rigide. Circa il 33,5% delle modifiche in una catena subisce un' "evoluzione strutturale" prima di essere finalmente unita (merged). Ciò significa che la connessione tra i domino cambia durante la revisione. Uno sviluppatore potrebbe decidere di staccare una modifica dal suo genitore e collegarla a un'altra, o l'intera catena potrebbe essere riorganizzata.

Questo aggiunge un altro livello di complessità: la mappa della catena è in costante mutamento. A volte, una catena può rimanere inattiva per molto tempo. Lo studio ha scoperto che il divario tra quando una parte di una catena viene inviata e quando viene finalmente unita può arrivare fino a 2,85 anni in alcuni casi!

Cosa Significa per il Futuro

Gli autori concludono che gli strumenti attuali per la revisione del codice spesso trattano ogni modifica come un evento isolato, come guardare un singolo mattone senza vedere il muro a cui appartiene. Questo articolo suggerisce che dobbiamo cambiare i nostri strumenti per comprendere la "catena" come un'unica unità.

Suggeriscono che se concentriamo la nostra attenzione sulla base della catena (il primo domino), possiamo risparmiare una quantità enorme di tempo per il resto della catena. Se la fondazione è solida, l'intera struttura si muove più velocemente. Propongono anche che gli strumenti debbano essere più intelligenti riguardo alle modifiche nel "mezzo", magari dando priorità a queste per sbloccare il resto della linea.

In breve, costruire software con le catene di relazione è come dirigere un'orchestra complessa. Se il direttore (la base) è fuori tempo, l'intera orchestra fatica. Ma se il direttore è chiaro e i musicisti (gli strumenti) comprendono come sono collegati gli strumenti, la musica scorre molto più velocemente. Lo studio suggerisce che, comprendendo queste connessioni, possiamo smettere di fare la fila e iniziare a costruire castelli in modo molto più efficiente.

Sintesi Tecnica: Come gli Sviluppatori Utilizzano le Catene di Relazione negli Ecosistemi di Review Basati su Gerrit

Problematica
I moderni flussi di lavoro di Modern Code Review (MCR) decompongono sempre più i grandi compiti ingegneristici in sequenze di cambiamenti dipendenti, spesso sottoposti come "cambiamenti impilati" (stacked changes). Nell'ecosistema Gerrit, queste dipendenze formano catene di relazione (relation chains): unità di revisione strutturate in cui lo stato di una revisione influenza direttamente la validazione, la sincronizzazione e la mergeabilità delle revisioni dipendenti. Mentre la ricerca empirica precedente ha analizzato estensivamente la revisione del codice a livello di singoli cambiamenti (focalizzandosi su latenza, dimensione e partecipazione dei revisori), ha ampiamente trascurato le catene di relazione come artefatti di prima classe. Gli studi esistenti o modellano le dipendenze tra repository in modo pairwise, o si affidano ad annotazioni testuali esplicite (es. Depends-On), o tracciano riferimenti nelle discussioni, fallendo nel catturare i grafi di dipendenza strutturali che determinano l'ordine di merge e le dinamiche di coordinamento inerenti alle catene. Di conseguenza, l'analisi delle revisioni, gli strumenti e i sistemi assistiti dall'IA operano sotto l'assunto che i cambiamenti siano unità indipendenti, rischiando di perdere i costi di coordinamento critici e i fattori strutturali che plasmano gli esiti della revisione.

Metodologia
Gli autori hanno condotto uno studio empirico attraverso tre distinti ecosistemi basati su Gerrit: OpenStack, Wikimedia e ONAP. Il dataset comprende 401.256 cambiamenti revisionati e 29.580 catene di relazione ricostruite da 15 repository.

Estrazione dei Dati: Lo studio ha utilizzato le API REST di Gerrit per estrarre i metadati dei cambiamenti, le revisioni dei patchset (inclusi gli SHA dei genitori), i diff a livello di file e i messaggi di revisione. Le catene sono state rilevate collegando i cambiamenti in cui lo SHA del genitore di un patchset corrispondeva all'ultimo SHA della revisione di un altro cambiamento in fase di revisione.
Metriche: Lo studio ha calcolato metriche per singolo cambiamento (revisioni, rebase, durata della revisione, messaggi di discussione, commenti inline, job CI/CD) e metriche per catena (profondità, gap di sottomissione, gap di merge). I cambiamenti sono stati stratificati per dimensione (da XS a XL) per controllare le variabili confondenti.
Analisi Statistica:
- RQ1 (Utilizzo): Sono stati utilizzati i test di trend di Mann–Kendall e la pendenza di Sen per analizzare le tendenze di adozione temporale.
- RQ2 (Esiti): Sono stati impiegati i test U di Mann–Whitney e il $\delta$ di Cliff per confrontare i membri delle catene con i cambiamenti "solo" (cambiamenti senza un genitore o un figlio in fase di revisione) di dimensioni equivalenti.
- RQ3 (Struttura): Le correlazioni di Spearman hanno analizzato la relazione tra l'attività del cambiamento base e l'attività media dei discendenti.
Ambito: L'analisi è osservativa; gli effetti riportati sono interpretati come associazioni piuttosto che conseguenze causali.

Contributi Chiave e Risultati

1. Prevalenza e Struttura (RQ1)

Adozione: Le catene di relazione sono prevalenti, variando dal 5% al 49% dei cambiamenti tra i progetti, con una mediana del 17%. L'adozione è in aumento in 14 dei 15 progetti studiati.
Profondità: Le catene sono prevalentemente superficiali. La profondità mediana è 2 (un base e un discendente) in 12 dei 15 progetti. Sebbene esistano catene profonde (es. un massimo di 98 in ONAP sdc), esse sono outlier rari.
Stabilità: Nonostante l'aumento dell'adozione, la forma strutturale (profondità) delle catene rimane stabile nel tempo. Le catene profonde corrispondono tipicamente a campagne ingegneristiche coordinate (es. campagne di refactoring) piuttosto che a rumore.

2. Esiti della Revisione: Catena vs. Solo (RQ2)

Overhead di Sincronizzazione: I membri delle catene impiegano un tempo mediano di 2,6 volte superiore per il merge rispetto ai cambiamenti "solo" di dimensioni equivalenti. Questo overhead è più pronunciato per i cambiamenti molto grandi (dimensione XL), dove il $\delta$ di Cliff raggiunge 0,49 (effetto grande).
Attività di Revisione: I membri delle catene non attirano più messaggi di discussione di alto livello rispetto ai cambiamenti "solo". Tuttavia, in OpenStack e Wikimedia, ricevono significativamente più commenti inline ancorati al codice, suggerendo un cambiamento nella forma del feedback piuttosto che nel volume.
Amplificazione CI: Sotto regimi di gating CI rigorosi (es. OpenStack), le catene di relazione mostrano un effetto di amplificazione CI. I membri della catena attivano da 10 a 23 job CI/CD per posizione, rispetto a meno di due per i cambiamenti "solo". Le revisioni di un membro riattivano la validazione su tutti i discendenti dipendenti.
Colli di Bottiglia: I membri centrali della catena fungono da colli di bottiglia per la sincronizzazione, assorbendo il maggior sforzo di revisione (revisioni, rebase, durata) perché sono simultaneamente bloccati dai predecessori e bloccano i successori.

3. Fattori Strutturali Intra-Catena (RQ3)

Il Gating CI Detta il Throughput: Il tempo tra i merge (merge gap) è determinato dal regime di gating CI del progetto piuttosto che dalla meccanica della catena. I progetti OpenStack presentano gap di merge di 2–10 ore a causa delle pipeline di test per ogni membro, mentre i progetti Wikimedia e ONAP spesso effettuano il merge entro pochi minuti una volta approvato il base.
L'Effetto Fondazione: Esiste una forte correlazione positiva ( $\rho = 0,43–0,61$ ) tra l'attività di revisione del cambiamento base e l'attività media dei suoi discendenti. Le catene con basi ad alto sforzo producono costantemente discendenti ad alto sforzo, suggerendo che lo sforzo di revisione si propaghi attraverso il grafo delle dipendenze.
Ristrutturazione Dinamica: Le catene non sono statiche. Il 33,5% dei membri delle catene subisce un cambiamento strutturale nel proprio SHA genitore prima del merge (es. distacco da un genitore in fase di revisione), spesso avvenendo a metà della revisione.
Longevità: Le catene possono persistere attraverso archi temporali pluriennali, con gap di merge che raggiungono fino a 2,85 anni in alcuni casi.

Significatività e Rivendicazioni
L'articolo sostiene che le catene di relazione sono unità di coordinamento durevoli e modellate dall'ecosistema con strutture interne che le analisi incentrate sul singolo cambiamento non possono catturare. Gli autori affermano che:

Gli Strumenti Attuali sono Disallineati: Gli strumenti di revisione predefiniti, che elaborano i cambiamenti in modo indipendente, non tengono conto dell'overhead di sincronizzazione, dell'amplificazione CI e delle dinamiche strutturali delle catene.
I Modelli Predittivi sono Incompleti: I modelli che predicono la latenza o lo sforzo di revisione basandosi solo su caratteristiche a livello di cambiamento omettono segnali critici a livello di catena (posizione, attività del base, evoluzione delle dipendenze) che correlano con gli esiti.
Intervento Strategico: L' "Effetto Fondazione" suggerisce un punto di intervento ad alta leva: concentrare l'attenzione della revisione sul cambiamento base può propagare i benefici (riduzione della frizione) in tutta la catena.
Direzioni Future: Gli autori invocano analisi di revisione consapevoli della catena (chain-aware), sistemi di assegnazione dei revisori che diano priorità ai cambiamenti che sbloccano il più grande sottografo a valle, e agenti di revisione assistiti dall'IA che si condizionino sulla posizione nella catena e sullo stato del cambiamento base.

Lo studio conclude che comprendere queste strutture di dipendenza è essenziale per un'analisi accurata delle revisioni e per strumenti efficaci nei moderni ecosistemi di ingegneria del software su larga scala.