demo técnica · software

Predecir qué ficheros tocará un arreglo
antes de escribirlo

Q: ¿Se puede predecir qué ficheros tocará un arreglo antes de escribirlo?

El fichero del arreglo real apareció entre los cinco candidatos el 58% de las veces. Quince años de pandas: 25.000 problemas resueltos y 37.000 cambios.

Si toco esto, ¿qué más habrá que tocar?

La pregunta no es solo de programadores: en cualquier sistema enredado, una tarifa que alimenta a otras, un contrato tipo, una hoja de cálculo encadenada, tocar una cosa arrastra a otras que no ves hasta que fallan.

llega un aviso. ¿dónde tocará el arreglo?

Tres avisos reales del examen, tal cual entraron. El sistema no lee el código: solo el título y el cuerpo del aviso, y la historia del proyecto congelada en su corte. Pulsa uno y mira dónde apunta.

sus cinco candidatos, en orden

1 el núcleo de agrupación coincide con el arreglo real
2 los métodos de agrupación
3 las operaciones de agrupación
4 el tronco común de tablas y series
5 las tablas

Acierto: el primer candidato coincide con el arreglo real, y el resto del top son sus vecinos de co-cambio.

El territorio: 15 ficheros de pandas con su papel en lugar de su nombre. Cada línea une dos ficheros que cambiaron juntos (grosor: cuántas veces, antes del corte de 2023); el tamaño de cada nodo, cuántas veces se tocó. En morado, los cinco candidatos del sistema en cada caso, con sus lazos de co-cambio; en ámbar, dónde tocó el arreglo real. Casos reales del examen, sin retocar.

Los ficheros reales detrás de cada papel

Los tres avisos son issues públicos de pandas: los números 45231 y 50634 (aciertos) y 45263 (el fallo; su arreglo tocó además la declaración de tipos del mismo módulo de valores nulos). Los papeles del mapa corresponden a estos ficheros:

la definición de los grupos · pandas/core/groupby/grouper.py
el núcleo de agrupación · pandas/core/groupby/groupby.py
la agrupación por categorías · pandas/core/groupby/categorical.py
los métodos de agrupación · pandas/core/groupby/generic.py
las operaciones de agrupación · pandas/core/groupby/ops.py
las tablas · pandas/core/frame.py
las columnas · pandas/core/series.py
el tronco común de tablas y series · pandas/core/generic.py
los índices · pandas/core/indexes/base.py
el formateo y la impresión · pandas/io/formats/format.py
el informe de versiones · pandas/util/_print_versions.py
las dependencias opcionales · pandas/compat/_optional.py
la instalación del paquete · setup.py
el código de bajo nivel de valores nulos · pandas/_libs/missing.pyx
el código de bajo nivel de fechas · pandas/_libs/tslib.pyx

Es la pregunta de todo el que mantiene un sistema grande. Para responderla usamos la historia completa de pandas, una de las librerías de software más usadas del mundo: quince años de cambios, con cada problema y cada arreglo documentados en público.

El experimento: cuando alguien reporta un problema, ¿puede un sistema que solo conoce la historia del proyecto predecir qué ficheros tocará el arreglo, antes de que exista? Sin leer el código a fondo: solo el texto del problema, qué ficheros cambiaron juntos durante años, y qué palabras viven en qué rincones.

Nada exótico en el método. Congelamos la historia en cuatro cortes (2021 a 2024). El sistema solo ve lo anterior a cada corte; los problemas del examen llegaron después. Los parámetros quedaron congelados antes de mirar un solo resultado, con huella criptográfica (769c68f). Y una decisión que nos costó casi la mitad del examen: descartamos todos los problemas cuyo texto fue editado después de crearse, porque no podemos garantizar que la versión que vemos sea la original. Preferimos un examen más pequeño y limpio que uno grande y trucable.

Lo que salió

Sobre 1.122 problemas del futuro: el sistema puso un fichero del arreglo real en su primera posición el 28% de las veces, y entre sus cinco candidatos el 58%. Apostar siempre por los ficheros más tocados históricamente se queda en el 8% y el 25%. Y la memoria de "qué cambia junto" añade sobre el texto solo: sin ella, la primera posición cae al 22%.

el fichero correcto, a la primera

el sistema 28%

solo el texto 22%

solo el co-cambio 15%

apostar a los de siempre 8%

Cuántas veces el primer candidato es ya el fichero correcto. Entre los cinco primeros, el sistema llega al 58% (apostar a los de siempre, 25%).

Tres avisos del examen, con su desenlace

Son los tres del mapa de arriba, tal cual salieron del examen. Un acierto: alguien reporta que agrupar una tabla vacía da error. El sistema propone como primer candidato el fichero central del subsistema de agrupación, exactamente donde el arreglo real tocó, y rellena el resto del top con ficheros del mismo vecindario.

Otro acierto: agrupar por categorías, con la tabla vacía, falla. El primer candidato fue el fichero que define cómo se forman los grupos, justo donde vivió el arreglo real.

Y un fallo: un reporte sobre "valores nulos que se imprimen mal" arrastró al sistema hacia ficheros de impresión y de entorno, cuando el arreglo vivía en el código de bajo nivel de valores nulos, que apenas comparte vocabulario con el reporte. El léxico solo no siempre basta; ese caso cuenta como fallo.

Cómo leer esto sin engañarse

Sin etiquetas de triaje. Las etiquetas de un issue las pone un mantenedor DESPUÉS de diagnosticar, usarlas sería meter la respuesta en la pregunta. El sistema solo ve el título y el cuerpo originales.
El examen es sobre arreglos localizados (un problema, un arreglo, pocos ficheros). La fracción que sobrevive ese filtro está publicada; un refactor gigante no se puede predecir así y no se finge lo contrario.
Techo declarado: el 3,5% de los arreglos tocaba solo ficheros que no existían al congelar la historia. Imposibles por construcción; cuentan como fallo.
Números con intervalo. Cada porcentaje lleva su intervalo de confianza al 95%.

Anexo: la pregunta hermana, y por qué no se contesta igual

Esta demo pregunta qué ficheros tocará un arreglo que todavía no existe. Hay otra pregunta que suena igual y no lo es: quién se rompe si cambio una pieza compartida hoy. La primera mira al futuro y es probable; la segunda mira al presente y es exacta.

Las medimos las dos con el mismo mapa de dependencias, y salieron respuestas opuestas. Para saber quién se rompe, el mapa encuentra 365 sitios donde buscar el nombre por el código encuentra uno. Para predecir qué tocará el arreglo, añadirlo a este sistema empeora el resultado: el acierto a la primera baja de 0,276 a 0,254 sobre el mismo examen. La memoria de qué cambia junto ya recogía lo que el mapa podía aportar, y además recoge lo que el código no dice.

El anexo completo, con las dos mediciones y el guion para reproducirlas →

Los peros

Un solo proyecto. pandas es grande y modular; en un proyecto con otra estructura el número será otro. La validación en un segundo proyecto queda propuesta como continuación.
El 44% de los problemas candidatos se excluyó por ediciones posteriores del texto (no verificables). El recorte completo está publicado, caso a caso.
Es un examen sobre historia cerrada de un proyecto público, no una herramienta validada universal.

Referencias

Esta idea tiene veinte años de literatura, y quien diga lo contrario vende humo. Lo que esta demo añade es el protocolo verificable: historia congelada por corte, entrada sin contaminar, parámetros pre-registrados y el techo y los fallos publicados.

Zimmermann, Weißgerber, Diehl & Zeller (ICSE 2004), Mining Version Histories to Guide Software Changes (la herramienta ROSE; versión extendida en IEEE TSE 2005).
Zhou, Zhang & Lo (ICSE 2012), Where should the bugs be fixed? (BugLocator).

Datos y agradecimientos

Esta prueba se sostiene sobre el trabajo del proyecto pandas y sus colaboradores, en abierto desde hace quince años. Gracias.

Sin afiliación con el proyecto. Los ejemplos citan ficheros y problemas públicos, nunca a las personas.

¿Puedes usar esto? Sí. Nuestro análisis, el mapa y los textos de esta página se publican bajo licencia CC BY 4.0: úsalos, compártelos o analízalos libremente, citando la fuente, Team Banzai (team-banzai.com). Los datos de terceros (el historial público del repositorio de pandas en GitHub) conservan las condiciones de sus fuentes originales, y el código del proyecto conserva su licencia propia.

Hecho con Python y SQLite. Recuperación léxica sobre rutas y mensajes de commit + grafo de co-cambio, mezclados con pesos congelados. Ningún modelo de lenguaje decide nada.

Sobre esta demo

Estudio retrospectivo con fines ilustrativos, sobre el repositorio público de pandas. Todos los problemas citados son históricos y están resueltos. Este análisis no evalúa al proyecto ni a sus colaboradores, y no constituye recomendación técnica sobre el software analizado.

¿Y en tu empresa?

El mismo método, aplicado al historial de averías de una fábrica, dice qué piezas suelen cambiarse juntas; aplicado a un archivo de contratos, qué cláusulas se tocan siempre a la vez; aplicado a los procesos de una empresa, qué departamentos se ven arrastrados cuando cambias uno.

Si alguno de estos experimentos te recuerda a un problema tuyo, un repositorio que solo entienden dos personas, cambios que rompen ficheros que nadie relacionaba, equipos que tocan lo mismo sin enterarse, escríbenos y lo comentamos. Sin rollo: te decimos si se puede o no.

← Todas las demos técnicas