💻 computer science

Combining Example-Based and Rule-Based Program Transformations to Resolve Build Conflicts

El artículo presenta BuCoR, una herramienta híbrida que combina transformaciones basadas en reglas y ejemplos para detectar y resolver conflictos de compilación en fusiones de código, logrando solucionar efectivamente 34 de 65 casos evaluados.

Autores originales: Sheikh Shadab Towqir, Fei He, Todd Mytkowicz, Na Meng

Publicado 2026-02-13

📖 4 min de lectura☕ Lectura para el café

CC BY 4.0

Autores originales: Sheikh Shadab Towqir, Fei He, Todd Mytkowicz, Na Meng

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 que dos arquitectos están trabajando en el mismo edificio de oficinas, pero desde diferentes planos.

El Arquitecto A decide cambiar el nombre de la "Sala de Juntas" por "Sala de Reuniones" y mueve las paredes.
El Arquitecto B, sin saberlo, decide instalar una nueva puerta que conduce exactamente a la "Sala de Juntas" (el nombre antiguo).

Cuando intentan unir sus planos en un solo documento maestro, ocurre un conflicto de construcción: el plano dice "puerta hacia la Sala de Juntas", pero esa sala ya no existe bajo ese nombre. Si intentas construir el edificio así, se derrumba.

En el mundo del software, esto sucede todos los días cuando los programadores intentan unir sus cambios. La mayoría de las herramientas actuales pueden decirte: "¡Oye, hay un error!", pero raramente saben cómo arreglarlo sin que un humano tenga que pasar horas reescribiendo código.

Aquí es donde entra BuCoR (el "Resolutor de Conflictos de Construcción"), una nueva herramienta presentada por investigadores de Virginia Tech, Tsinghua y Google.

¿Cómo funciona BuCoR? (La analogía del Detective y el Manual)

BuCoR es como un equipo de dos expertos trabajando juntos para arreglar el plano del edificio:

1. El Detective (BuCoR-E: Basado en Ejemplos)

Imagina que el Arquitecto A, en su propio departamento, tuvo un problema similar antes: cambió el nombre de una sala y tuvo que actualizar todas las puertas y letreros que apuntaban a ella.

Lo que hace BuCoR-E: Busca en los historiales de los arquitectos (las ramas del código) para ver si alguien ya resolvió un problema parecido.
La magia: No solo copia el cambio de nombre. El detective observa todo el contexto: "Ah, cuando cambiaron el nombre de la sala, también cambiaron el color de la puerta y el tipo de cerradura".
El resultado: BuCoR-E aprende de ese ejemplo pasado y aplica ese mismo patrón inteligente a tu conflicto actual. Es como decir: "He visto cómo arreglaste esto la semana pasada en otra parte del edificio, así que haré exactamente lo mismo aquí".

2. El Experto del Manual (BuCoR-R: Basado en Reglas)

A veces, el detective no encuentra ningún ejemplo previo. ¿Qué hacemos entonces? Aquí entra el experto que tiene un manual de instrucciones muy grueso.

Lo que hace BuCoR-R: Tiene 16 reglas predefinidas para los errores más comunes. Por ejemplo: "Si alguien elimina un archivo y otro lo usa, la regla dice: 'Vuelve a poner el archivo' o 'Actualiza la referencia'".
La magia: Es rápido y seguro para problemas estándar. Si el conflicto es simple (como un cambio de nombre), el manual sabe exactamente qué hacer sin necesidad de buscar en el pasado.

La Gran Combinación

La genialidad de BuCoR es que usa a ambos al mismo tiempo.

Primero, detecta el conflicto (como un inspector de obras que ve que la puerta no encaja).
Luego, consulta al Manual (Reglas) para soluciones rápidas y estándar.
Al mismo tiempo, consulta al Detective (Ejemplos) para ver si hay una solución más creativa y específica para ese proyecto en particular.

Si el Manual dice "cambia el nombre", pero el Detective ve que en este proyecto específico también hay que cambiar el color de la pared, BuCoR sugiere la solución completa.

¿Qué tan bien funciona?

Los investigadores probaron BuCoR con 88 conflictos reales de proyectos de software de código abierto.

El resultado: Logró proponer una solución para el 74% de los casos.
La precisión: De las soluciones que propuso, la mitad (52%) eran correctas y listas para usarse.
El hallazgo clave: Cuando usaron solo el Manual, resolvieron muchos casos pero a veces de forma incorrecta. Cuando usaron solo al Detective, resolvieron menos casos, pero cuando lo hacía, ¡suele ser más preciso y creativo! Juntos, se complementan perfectamente.

En resumen

Piensa en BuCoR como un asistente de construcción inteligente que no solo sabe leer las reglas del código, sino que también tiene una memoria increíble para recordar cómo se arreglaron problemas similares en el pasado.

En lugar de dejar que el programador tenga que adivinar cómo unir dos piezas de un rompecabezas que no encajan, BuCoR le dice: "Mira, aquí hay una solución estándar, pero si miramos lo que hicimos antes en este proyecto, la mejor solución es esta otra".

Esto ahorra horas de frustración, evita errores costosos y permite que el software se construya más rápido y mejor.

1. El Problema: Conflictos de Construcción en la Fusión de Código

En el desarrollo de software colaborativo, los desarrolladores integran cambios de diferentes ramas (branches) mediante fusiones (merges). Aunque las herramientas de control de versiones (como Git) detectan conflictos textuales (cuando dos ramas editan la misma línea de código), a menudo pasan por alto los conflictos de construcción (build conflicts).

Definición: Un conflicto de construcción ocurre cuando la integración ingenua de cambios de dos ramas (una versión base $b$ , una izquierda $l$ y una derecha $r$ ) resulta en un código que no se compila o falla en las pruebas.
Causas: Estos conflictos no se deben solo a solapamientos textuales, sino a incompatibilidades semánticas, como:
- Renombrado de símbolos (clases, métodos) en una rama y su uso en la otra.
- Cambios en la jerarquía de clases.
- Adición o eliminación de parámetros, tipos de retorno o definiciones de campos.
Limitaciones actuales: Las herramientas existentes (como Gmerge o MrgBldBrkFixer) se centran principalmente en el renombrado de símbolos y sugieren soluciones simples (ej. cambiar el nombre de una variable). Fallan ante conflictos más complejos que requieren cambios estructurales profundos o contextuales, obligando a los desarrolladores a realizar correcciones manuales tediosas y propensas a errores.

2. Metodología: BuCoR (BUild COnflict Resolver)

El artículo presenta BuCoR, una nueva herramienta que combina dos estrategias complementarias para resolver estos conflictos: Transformación Basada en Ejemplos (BuCoR-E) y Transformación Basada en Reglas (BuCoR-R).

Componentes Principales

Detección de Conflictos (Bucond):
- Utiliza análisis estático para comparar las versiones $b$ , $l$ y $r$ .
- Modela cada versión como un Grafo de Entidades del Programa (PEG) que captura definiciones y relaciones (llamadas a métodos, referencias de tipos).
- Compara los PEGs para identificar cambios de entidades que generan conflictos, sin necesidad de compilar la versión fusionada ingenua ( $A_m$ ).
Construcción de Grafos de Cuatro Vías:
- BuCoR genera una versión fusionada ingenua ( $A_m$ ) usando git-merge.
- Construye un grafo unificado que conecta los PEGs de $b$ , $l$ , $r$ y $A_m$ . Esto permite alinear el contexto del código y ubicar con precisión dónde aplicar las correcciones.
Estrategia 1: Transformación Basada en Ejemplos (BuCoR-E)
- Filosofía: Asume que si un desarrollador resolvió un error de construcción similar en una rama (ej. ajustando el uso de una clase renombrada), ese patrón puede aplicarse al conflicto de fusión.
- Proceso:
  1. Minería de Ejemplos: Identifica el cambio de definición (def) responsable del conflicto y busca en la rama correspondiente ejemplos de cómo los desarrolladores ajustaron los usos existentes de esa entidad.
  2. Inferencia de Patrones: Extrae un patrón de transformación del ejemplo encontrado. Utiliza análisis de dependencias (control y datos) para refinar el patrón, eliminando contexto irrelevante pero manteniendo las operaciones esenciales.
  3. Aplicación de Patrones: Realiza una coincidencia de contexto ("context matching") entre el patrón inferido y el código en la versión fusionada ( $A_m$ ). Si hay coincidencia, aplica las operaciones de edición (AST rewriting) para resolver el conflicto.
- Ventaja: Capaz de manejar soluciones no convencionales y específicas del proyecto.
Estrategia 2: Transformación Basada en Reglas (BuCoR-R)
- Filosofía: Utiliza un conjunto predefinido de reglas para conflictos frecuentes.
- Implementación: Define 16 reglas de resolución que cubren tipos comunes de conflictos (renombrado de clases, cambios en listas de parámetros, eliminación de imports, etc.).
- Proceso: Para cada conflicto, busca una regla aplicable en su conjunto y la personaliza para el contexto específico.
- Ventaja: Alta cobertura para conflictos convencionales y bien documentados.

3. Contribuciones Clave

Hibridación Innovadora: BuCoR es la primera herramienta que combina sistemáticamente el aprendizaje basado en ejemplos (minería de repositorios) con reglas estructuradas para resolver conflictos de construcción.
Análisis de Dependencias Avanzado: BuCoR-E utiliza análisis de dependencias para inferir patrones de resolución que van más allá del simple renombrado, ajustando variables, literales y llamadas a métodos relacionados.
Cobertura Amplia de Tipos de Conflictos: A diferencia de herramientas anteriores limitadas al renombrado, BuCoR aborda 21 tipos distintos de conflictos, incluyendo cambios en jerarquías de clases y firmas de métodos.
Dataset y Evaluación: Se creó un dataset de 88 conflictos de construcción reales extraídos de 30 proyectos de código abierto, abarcando 21 tipos de conflictos.

4. Resultados Experimentales

La evaluación se realizó sobre los 88 conflictos reales:

Cobertura (Coverage): BuCoR generó al menos una solución para 65 de los 88 casos (74%).
- BuCoR-E resolvió 28 casos.
- BuCoR-R resolvió 51 casos.
- La combinación demostró que las estrategias se complementan: BuCoR-R cubre casos donde no hay ejemplos, y BuCoR-E cubre casos donde no hay reglas estándar.
Precisión (Accuracy): De las 79 soluciones generadas, 41 fueron correctas (52%).
- BuCoR-E: 75% de precisión (21/28). Es más preciso porque imita las soluciones reales de los desarrolladores.
- BuCoR-R: 39% de precisión (20/51). Tiene mayor cobertura pero menor precisión, ya que las reglas predefinidas no siempre capturan las preferencias específicas del proyecto.
Resolución Correcta Total: BuCoR resolvió correctamente 34 conflictos en total.
Rendimiento: El tiempo de ejecución varió de 0.1 a 53.6 minutos por escenario de fusión (promedio 2.9 min), dependiendo del tamaño del proyecto.

5. Significado e Impacto

Este trabajo representa un avance significativo en la automatización de la integración de software:

Más allá del renombrado: Demuestra que los conflictos de construcción pueden resolverse mediante transformaciones de programa complejas y contextuales, no solo cambios de texto.
Reducción de carga cognitiva: Al ofrecer soluciones automáticas que imitan el comportamiento humano (BuCoR-E) o siguen mejores prácticas (BuCoR-R), reduce el tiempo que los desarrolladores dedican a depurar fusiones fallidas.
Dirección futura: El estudio sugiere que las herramientas de fusión futuras deben integrar aprendizaje basado en ejemplos con reglas estructuradas para manejar la diversidad de escenarios de integración en el mundo real.

En resumen, BuCoR es una herramienta robusta que utiliza análisis estático y minería de ejemplos para automatizar la resolución de errores de compilación derivados de la fusión de código, superando las limitaciones de las herramientas actuales que se centran únicamente en conflictos textuales o de renombrado simple.