💻 computer science

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

Este estudio empírico de casi 30.000 cadenas de relación a través de tres ecosistemas basados en Gerrit revela que, si bien las secuencias de cambios vinculadas por dependencias son cada vez más frecuentes, estas extienden significativamente los tiempos de fusión y propagan el esfuerzo de revisión, lo que requiere que las futuras herramientas y analíticas de revisión evolucionen para razonar sobre estas cadenas estructuradas en lugar de cambios aislados.

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

Publicado 2026-07-23

📖 7 min de lectura🧠 Análisis profundo

CC BY 4.0

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

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

Imagina un mundo donde construir software es como construir un castillo enorme e intrincado. En este mundo, los desarrolladores no solo lanzan ladrillos contra una pared y esperan que se queden pegados; utilizan un sistema riguroso llamado Revisión de Código (Code Review). Antes de que cualquier nuevo ladrillo (o línea de código) se añada permanentemente al castillo, un equipo de inspectores lo revisa para buscar grietas, asegurar que encaje con el diseño y comprobar que no rompa nada más. Este proceso es vital para mantener el castillo en pie y seguro.

Sin embargo, a veces, un proyecto es demasiado grande para ser un solo ladrillo. Es una torre entera la que debe construirse. En el pasado, los desarrolladores podrían haber intentado construir la torre completa de una sola vez, pero eso es difícil de inspeccionar. Por ello, empezaron a dividirla en una secuencia de pasos más pequeños y conectados. En el mundo del software, específicamente dentro de una herramienta llamada Gerrit, estos pasos conectados se denominan Cadenas de Relación (Relation Chains). Piensa en una cadena de relación como un conjunto de fichas de dominó colocadas en fila: aunque no puedes derribar la tercera hasta que caiga la segunda, y la segunda hasta que caiga la primera, los inspectores pueden revisar todas ellas al mismo tiempo, pero el castillo solo puede completarse en orden. Toda la cadena está vinculada; si la primera ficha (la "base") es inestable, toda la línea está en problemas. Comprender cómo funcionan estas cadenas es crucial porque, si el sistema es demasiado lento o confuso, los desarrolladores podrían quedarse estancados esperando durante horas, o el castillo podría construirse con grietas ocultas.

El Efecto Dominó: Cómo usan las Cadenas de Código los Desarrolladores en la Realidad

Este artículo es una inmersión profunda en cómo los desarrolladores de tres comunidades de código abierto masivas (OpenStack, Wikimedia y ONONAP) utilizan estas "Cadenas de Relación" para construir software. Los investigadores analizaron cerca de 30,000 cadenas y más de 400,000 cambios de código individuales para ver cómo se comportan estos dominós vinculados en el mundo real. Querían saber: ¿Son estas cadenas comunes? ¿Hacen que el proceso de revisión sea más rápido o más lento? Y, ¿qué sucede cuando intentas arreglar un dominó en medio de la línea?

Las Cadenas están en Todas Partes (y se están Haciendo más Grandes)

Primero, el estudio encontró que estas cadenas no son un truco raro o de nicho; son una forma estándar de trabajar. Dependiendo del proyecto, entre el 5% y el 49% de todos los cambios de código forman parte de una cadena. De hecho, en 14 de los 15 proyectos estudiados, el uso de estas cadenas está, de hecho, aumentando con el tiempo. Los desarrolladores se están dando cuenta de que dividir las grandes tareas en piezas más pequeñas y vinculadas es el camino a seguir.

La mayoría de estas cadenas son cortas, usualmente un par de fichas (un cambio base y un cambio dependiente). Sin embargo, algunos proyectos tienen cadenas que se extienden increíblemente profundo. ¡Los investigadores encontraron cadenas con hasta 98 miembros! Un proyecto incluso tuvo una cadena generada automáticamente con casi 60,000 miembros, aunque ese fue un caso especial de configuración automatizada, no de escritura humana.

El "Medio" es el Cuello de Botella

Aquí es donde se pone interesante. Los investigadores descubrieron que estar en el medio de una cadena es el trabajo más difícil. Si eres la primera ficha (la "base"), solo tienes que esperar tu propia revisión. Si eres la última (la "cima"), solo esperas a las anteriores. Pero si estás en el medio, estás atrapado en un pellizco. Estás bloqueado por la ficha de antes de ti (esperando a que sea aprobada) mientras simultáneamente bloqueas a las fichas que vienen después de ti.

Debido a este "pellizco", los cambios en el medio de una cadena tardan significante más tiempo en ser aprobados. El estudio encontró que, en promedio, los miembros de una cadena tardan 2.6 veces más en integrarse (merge) que los cambios aislados de su mismo tamaño. Este retraso no se debe a que el código sea peor; se debe a la "sobrecarga de sincronización". Aunque los inspectores (revisores) pueden revisar los ladrillos en paralelo, la integración real en el castillo debe ocurrir uno por uno, de abajo hacia arriba. Cada vez que se retoca un cambio en la cadena, a menudo obliga a que toda la línea sea revisada, probada y reordenada, creando un cuello de botella donde los cambios del medio esperan a los que están debajo de ellos mientras también retienen a los que están arriba.

El Monstruo de la "Amplificación de CI"

El artículo también destaca un fenómeno que llaman el efecto de amplificación de CI. "CI" significa Integración Continua, que es como un ejército de robots que prueba automáticamente cada nuevo ladrillo para asegurar que no rompa el castillo. En proyectos con reglas estrictas (como OpenStack), cada vez que un desarrollador actualiza un cambio en una cadena, el ejército de robots tiene que volver a probar ese cambio y todos los cambios que dependen de él.

El estudio encontró que los miembros de una cadena activan entre 10 y 23 trabajos de pruebas automatizadas, mientras que un cambio único y aislado podría activar menos de dos. Es como si tuvieras que volver a probar toda tu casa cada vez que cambias una sola bombilla. Esto crea una cantidad masiva de trabajo extra para las computadoras y retrasos para los humanos.

El "Efecto de la Fundación"

Uno de los hallazgos más fascinantes es lo que los autores llaman el Efecto de la Fundación. Descubrieron que la cantidad de esfuerzo dedicado a la primera ficha (la base) predice cuánto esfuerzo se dedicará a todas las fichas que le siguen.

Si el cambio base recibe mucha atención, muchos comentarios y muchas rondas de revisión, toda la cadena tiende a seguir ese patrón. Los investigadores encontraron un vínculo fuerte (una correlación de 0.43 a 0.61) entre la actividad en la base y la actividad en los descendientes. Es como si la "vibra" de la primera ficha marcara el tono para toda la línea. Si la fundación es inestable y requiere mucho arreglo, toda la torre tarda más en construirse. Por el contrario, si la base es sólida y se aprueba rápidamente, el resto de la cadena tiende a fluir sin problemas.

Las Cadenas no son Estáticas

Finalmente, el artículo revela que estas cadenas no son estructuras rígidas. Aproximadamente el 33.5% de los cambios en una cadena experimentan una "evolución estructural" antes de ser finalmente integrados. Esto significa que la conexión entre los dominós cambia mientras están siendo revisados. Un desarrollador puede decidir desvincular un cambio de su padre y vincularlo a uno diferente, o toda la cadena podría reorganizarse.

Esto añade otra capa de complejidad: el mapa de la cadena cambia constantemente. A veces, una cadena puede permanecer inactiva durante mucho tiempo. El estudio encontró que la brecha entre cuando una parte de una cadena es enviada y cuando finalmente se integra puede extenderse hasta 2.85 años en algunos casos.

Qué Significa esto para el Futuro

Los autores concluyen que las herramientas actuales para revisar código a menudo tratan cada cambio como un evento aislado, como mirar un solo ladrillo sin ver la pared a la que pertenece. Este artículo sugiere que necesitamos cambiar nuestras herramientas para entender la "cadena" como una unidad completa.

Sugieren que si centramos nuestra atención en la base de la cadena (la primera ficha), podemos ahorrar una cantidad masiva de tiempo para el resto de la cadena. Si la fundación es sólida, toda la estructura se mueve más rápido. También proponen que las herramientas deberían ser más inteligentes con los cambios del "medio", quizás priorizándolos para desbloquear el resto de la línea.

En resumen, construir software con cadenas de relación es como dirigir una orquesta compleja. Si el director (la base) pierde el ritmo, toda la orquesta sufre. Pero si el director es claro y los músicos (las herramientas) entienden cómo están vinculados los instrumentos, la música fluye mucho más rápido. El estudio sugiere que, al comprender estas conexiones, podemos dejar de esperar en fila y empezar a construir castillos de manera mucho más eficiente.

Resumen Técnico: Cómo los Desarrolladores Utilizan las Cadenas de Relación en los Ecosistemas de Revisión Basados en Gerrit

Planteamiento del Problema
Los flujos de trabajo de la Revisión de Código Moderna (MCR, por sus siglas en inglés) descomponen cada vez más las grandes tareas de ingeniería en secuencias de cambios dependientes, que a menudo se presentan como "cambios apilados" (stacked changes). En el ecosistema de Gerrit, estas dependencias forman cadenas de relación: unidades de revisión estructuradas donde el estado de una revisión influye directamente en la validación, sincronización y capacidad de fusión de las revisiones dependientes. Aunque la investigación empírica previa ha analizado extensamente la revisión de código a nivel de cambios aislados (centrándose en latencia, tamaño y participación de los revisores), ha pasado por alto en gran medida las cadenas de relación como artefactos de primera clase. Los estudios existentes o bien modelan dependencias de repositorios por pares, dependen de anotaciones textuales explícitas (p. ej., Depends-On), o rastrean referencias de discusión, fallando al capturar los grafos de dependencia estructurales que determinan el orden de fusión y la dinámica de coordinación inherente a las cadenas. En consecuencia, la analítica de revisión, las herramientas y los sistemas asistidos por IA operan bajo el supuesto de que los cambios son unidades independientes, lo que potencialmente ignocia los costos de coordinación críticos y los factores estructurales que moldean los resultados de la revisión.

Metodología
Los autores realizaron un estudio empírico en tres ecosistemas distintos basados en Gerrit: OpenStack, Wikimedia y ONAP. El conjunto de datos comprende 401,256 cambios revisados y 29,580 cadenas de relación reconstruidas de 15 repositorios.

Extracción de Datos: El estudio utilizó la API REST de Gerrit para extraer metadatos de cambios, revisiones de parches (incluyendo SHAs de padres) y diffs a nivel de archivo, así como mensajes de revisión. Las cadenas se detectaron vinculando cambios donde el SHA del padre de un parche coincidía con el SHA de la última revisión de otro cambio en proceso de revisión.
Métricas: El estudio computó métricas por cambio (revisiones, rebasamientos, duración de la revisión, mensajes de discusión, comentarios en línea, trabajos de CI/CD) y métricas por cadena (profundidad, brechas de envío, brechas de fusión). Los cambios se estratificaron por tamaño (de XS a XL) para controlar variables de confusión.
Análisis Estadístico:
- RQ1 (Uso): Se utilizaron pruebas de tendencia de Mann–Kendall y la pendiente de Sen para analizar las tendencias de adopción temporal.
- RQ2 (Resultados): Se emplearon pruebas de Mann–Whitney U y el $\delta$ de Cliff para comparar los miembros de la cadena frente a cambios "solitarios" (solo) del mismo tamaño (cambios sin un padre o hijo en revisión).
- RQ3 (Estructura): Las correlaciones de Spearman analizaron la relación entre la actividad del cambio base y la actividad media de los descendientes.
Alcance: El análisis es observacional; los efectos reportados se interpretan como asociaciones y no como consecuencias causales.

Contribuciones Clave y Resultados

1. Prevalencia y Estructura (RQ1)

Adopción: Las cadenas de relación son prevalentes, variando entre el 5% y el 49% de los cambios en los proyectos, con una mediana del 17%. La adopción está aumentando en 14 de los 15 proyectos estudiados.
Profundidad: Las cadenas son predominantemente superficiales. La profundidad mediana es de 2 (una base y un descendiente) en 12 de 15 proyectos. Existen cadenas profundas (por ejemplo, una profundidad máxima de 98 en ONAP sdc), pero son valores atípicos poco comunes.
Estabilidad: A pesar del aumento en la adopcción, la forma estructural (profundidad) de las cadenas permanece estable en el tiempo. Las cadenas profundas suelen corresponder a campañas de ingeniería coordinadas (p. ej., barridos de refactorización) en lugar de ruido.

2. Resultados de la Revisión: Cadena vs. Solitario (RQ2)

Sobrecarga de Sincronización: Los miembros de la cadena tardan una mediana de 2.6× más en fusionarse que los cambios solitarios del mismo tamaño. Esta sobrecarga es más pronunciada para cambios muy grandes (tamaño XL), donde el $\delta$ de Cliff alcanza 0.49 (efecto grande).
Actividad de Revisión: Los miembros de la cadena no atraen más mensajes de discusión de alto nivel que los cambios solitarios. Sin embargo, en OpenStack y Wikimedia, reciben significativamente más comentarios en línea anclados al código, lo que sugiere un cambio en la forma del feedback más que en el volumen.
Amplificación de CI: Bajo regímenes estrictos de control por CI (p. ej., OpenStack), las cadenas de relación exhiben un efecto de amplificación de CI. Los miembros de la cadena activan entre 10 y 23 trabajos de CI/CD por posición, comparado con menos de dos para los cambios solitarios. Las revisiones de un miembro re-activan la validación en todos los descendientes dependientes.
Cuellos de Botella: Los miembros situados en medio de la cadena funcionan como cuellos de botella de sincronización, absorbiendo el mayor esfuerzo de revisión (revisiones, rebasamientos, duración) porque están simultáneamente bloqueados por predecesores y bloqueando sucesores.

3. Factores Estructurales Intra-Cadena (RQ3)

El Control de CI Dicta el Rendimiento: El tiempo entre fusiones (brecha de fusión) está determinado por el régimen de control de CI del proyecto en lugar de la mecánica de la cadena. Los proyectos de OpenStack exhiben brechas de fusión de 2 a 10 horas debido a los canales de prueba por cada miembro, mientras que los proyectos de Wikimedia y ONAP a menudo fusionan en minutos una vez aprobado el base.
El Efecto de la Fundación: Existe una fuerte correlación positiva ( $\rho = 0.43–0.61$ ) entre la actividad de revisión del cambio base y la actividad media de sus descendientes. Las cadenas con bases de alto esfuerzo resultan consistentemente en descendientes de alto esfuerzo, lo que sugiere que el esfuerzo de revisión se propaga a través del grafo de dependencia.
Reestructuración Dinámica: Las cadenas no son estáticas. El 33.5% de los miembros de la cadena experimentan un cambio estructural en su SHA de padre antes de la fusión (p. ej., desvinculándose de un padre en revisión), ocurriendo a menudo a mitad de la revisión.
Longevidad: Las cadenas pueden persistir a través de periodos de varios años, con brechas de fusión que alcanzan hasta 2.85 años en algunos casos.

Significancia y Reivindicaciones
El artículo argumenta que las cadenas de relación son unidades de coordinación duraderas y moldeadas por el ecosistema con estructuras internas que los análisis centrados en cambios individuales no pueden capturar. Los autores afirman que:

Las Herramientas Actuales están Desalineadas: Las herramientas de revisión por defecto, que procesan los cambios de forma independiente, no tienen en cuenta la sobrecarga de sincronización, la amplificación de CI y las dinámicas estructurales de las cadenas.
Los Modelos Predictivos están Incompletos: Los modelos que predicen la latencia o el esfuerzo de revisión basándose únicamente en características a nivel de cambio omiten señales críticas a nivel de cadena (posición, actividad de la base, evolución de la dependencia) que se correlacionan con los resultados.
Intervención Estratégica: El "Efecto de la Fundación" sugiere un punto de intervención de alto apalancamiento: concentrar la atención de la revisión en el cambio base puede propagar beneficios (reducción de fricción) a través de toda la cadena.
Direcciones Futuras: Los autores hacen un llamado a la analítica de revisión consciente de las cadenas, sistemas de asignación de revisores que prioricen cambios que desbloqueen el subgrafo descendente más grande, y agentes de revisión asistidos por IA que condicionen su actuación a la posición en la cadena y al estado del cambio base.

El estudio concluye que comprender estas estructuras de dependencia es esencial para una analítica de revisión precisa y para una instrumentación efectiva en los ecosistemas modernos de ingeniería de software a gran escala.