Back home

Al modernizar sistemas antiguos, Copilot primero clasifica la evidencia

Primero arregle la línea base, la superficie de modificación y los límites de prueba antes de que el modelo esté calificado para ayudar.

Al modernizar el antiguo sistema, Copilot primero organiza la evidencia

La primera vez que instalé un proyecto Java de la era 1.5 en una máquina moderna, lo primero que apareció no fue el problema del código, sino el problema de la evidencia. Si la compilación se puede reproducir, si el resultado de la prueba es el mismo, si el punto de falla proviene de la JVM, la imagen o el código fuente, estas cosas determinan cómo proceder antes de “comenzar a refactorizar”. El mayor temor al modernizar sistemas antiguos no es que los cambios sean lentos, sino que sea imposible saber qué pasó después de los cambios.

Primero arregle la escena, luego las acciones posteriores serán significativas. Lo más valioso en ese paso no es la finalización en el IDE, sino un cuadro que se puede ejecutar repetidamente: el JDK antiguo, las herramientas de compilación antiguas, las entradas antiguas y los comandos de prueba antiguos están todos bloqueados en Docker. Comandos como los siguientes no son bonitos, pero funcionan:

docker run --rm -v "$PWD":/src -w /src legacy-jdk8 \
  sh -lc './gradlew test 2>&1 | tee logs/baseline.log'

Este comando tiene sólo una función: convertir el “fracaso de hoy” en evidencia reproducible. Sin él, cada éxito posterior podría ser simplemente el resultado de circunstancias que resultaron indulgentes. El papel del copiloto aquí también es muy claro. No es para reemplazar el juicio, sino para ayudar a clasificar los rastros: errores repetidos en registros largos, rutas que se hacen eco entre sí en los scripts de compilación y varias entradas recurrentes en pruebas antiguas se pueden usar primero para una evaluación aproximada. Lo que se extrae no es una conclusión, sino un mapa para empezar.

Cuando llega el momento de pasar por el quirófano, el área de cambio debe ser muy estrecha. La forma más fácil de anular proyectos antiguos es cambiar el nombre del paquete, la compilación, la entrada y la prueba, todo a la vez. Al final, ni siquiera se puede decir qué paso rompió el sistema. Un enfoque más estable es aprovechar primero el espacio más pequeño: por ejemplo, cubrir la entrada anterior con una capa de adaptadores, primero permitir que la nueva cadena de herramientas permanezca fuera del viejo mundo y ver la estructura con claridad, y luego moverse lentamente hacia adentro. Copilot es muy adecuado para manejar este tipo de trabajo mecánico: llenar importaciones, mover configuraciones, extraer fragmentos repetidos y generar esqueletos de prueba temporales. Dejemos que el modelo haga estas cosas y la eficiencia será realmente alta; pero todavía depende de las personas decidir si esta costura debe cortarse y qué comportamiento debe conservarse después del corte.

También es fácil dejarse engañar por las apariencias cuando se trata de pruebas. Pasar la vieja prueba no significa que la modernización sea segura, sólo significa que ciertos comportamientos históricos aún no se han roto. Las pruebas de muchos proyectos antiguos se parecen más a instantáneas de comportamiento que a especificaciones semánticas de negocios. El verde es simplemente verde y no puede interpretarse directamente como “comprender el sistema”. Una de las acciones más importantes durante la transformación es agregar límites de prueba nuevos y más estrechos a cada pequeña incisión, de modo que la prueba cambie gradualmente de “legado histórico” a “limitaciones actuales”. Copilot puede ayudar a desglosar afirmaciones antiguas, completar plantillas y desplegar shells de prueba duplicados. Sin embargo, qué semántica debe mantenerse en la prueba y el modelo no puede tomar decisiones para el sistema.

En la modernización arqueológica, la división del trabajo más confiable es en realidad muy simple: el entorno y los registros son responsables de precisar los hechos, Copilot es responsable de mover ladrillos y traducir, y las personas son responsables de decidir qué historia debe conservarse y qué historia debe eliminarse. Una vez que se organiza un modelo para explicar el pasado del sistema, a menudo las conjeturas resultan más convincentes que la evidencia; Volviendo a colocarlo en la posición de gestión de evidencia y organización mecánica, se vuelve más como un asistente verdaderamente útil.