demo técnica · software
Predecir qué ficheros tocará un arreglo
antes de escribirlo
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
- 1 la definición de los grupos coincide con el arreglo real
- 2 el núcleo de agrupación
- 3 los métodos de agrupación
- 4 la agrupación por categorías
- 5 las operaciones de agrupación
- 1 el informe de versiones
- 2 la instalación del paquete
- 3 las tablas
- 4 las dependencias opcionales
- 5 el código de bajo nivel de fechas
Acierto: el primer candidato coincide con el arreglo real, y el resto del top son sus vecinos de co-cambio.
Acierto: el primer candidato, la definición de los grupos, es exactamente donde tocó el arreglo real.
Fallo: ninguno de los cinco. El texto del aviso arrastró al sistema hacia la impresión y el entorno; el arreglo real vivía en el código de bajo nivel de valores nulos y en los índices. Cuenta como fallo en el número.
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
resumen
- los datos
- El repositorio de código de pandas en GitHub: quince años de historia pública, con más de 25.000 problemas resueltos y 37.000 cambios integrados.
- la pregunta
- Cuando alguien reporta un fallo nuevo, ¿se puede adivinar en qué ficheros habrá que trabajar, antes de que nadie lo arregle?
- la prueba
- El sistema solo conoce la historia del proyecto hasta una fecha. Con cada fallo reportado después, propone sus candidatos. Luego abrimos el arreglo real y comparamos.
- lo que salió
- En uno de cada cuatro problemas, el primer candidato del sistema era ya el fichero correcto. Y mirando sus cinco candidatos, el correcto aparecía en más de la mitad de los casos. Para comparar: apostar siempre por los ficheros más retocados acierta a la primera menos de una de cada diez veces.
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
Tres casos, con el futuro abierto
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%.
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.