Modernice primero el sistema antiguo y construya la escalera de compatibilidad

La primera vez que abrí un proyecto Java hace veinte años, lo primero que vi no fue el olor del código, sino el olor a antigüedad. El build.xml todavía está ahí, pero el pom.xml no está ahí; la estructura del directorio está pasada de moda, la entrada de prueba también está pasada de moda e incluso es necesario reconfirmar “si se puede reconstruir un producto ejecutable”. El error más común en esta etapa es centrarse en clases y métodos e ignorar que lo que realmente bloquea la modernización es el entorno y la entrada.

Lo primero que hay que hacer al modernizar sistemas antiguos es crear una escalera de compatibilidad. La base de la escalera normalmente sólo tiene una cosa: hacer que el antiguo sistema funcione de manera estable dentro de las antiguas reglas y, preferiblemente, servir como una cápsula del tiempo. Docker, JDK antiguo, herramientas de compilación antiguas, comandos de prueba antiguos, estas cosas parecen toscas, pero son muy efectivas. Mientras esta base no esté en posición vertical, cada cambio posterior generará nuevo ruido: ya sea el código que está roto o la JVM, la imagen, la arquitectura y los complementos que están rotos, es imposible saberlo.

Luego llegó el turno de elegir el puente. El objetivo del puente es muy específico: un extremo está conectado al código fuente antiguo y el otro extremo está conectado a la nueva máquina. Este proyecto finalmente recayó en Java 8 y Gradle 7.6, que simplemente se atascaron en las limitaciones de ambos extremos: Java 17 ya no está dispuesto a compilar el código fuente de Java 1.5 y Java 6 no puede ejecutarse en el entorno nativo de ARM64. Si el puente está mal, la modernización quedará estancada en la cadena de herramientas; si el puente es correcto, las migraciones posteriores podrán avanzar paso a paso.

Lo más útil aquí es dejar que el modelo grande se encargue de organizar y traducir. Puede ayudar a traducir la lógica de Ant a Gradle, mapear directorios al diseño anterior y eliminar esas configuraciones repetitivas y mecánicas. Por ejemplo, apunte explícitamente el directorio del código fuente a la ruta anterior y agregue una tarea personalizada para ejecutar la prueba main() anterior:

java {
    sourceCompatibility = JavaVersion.VERSION_1_5
    targetCompatibility = JavaVersion.VERSION_1_5
}
sourceSets {
    main {
        java {
            srcDirs = ['java']
        }
    }
}
tasks.register('runLegacyTest', JavaExec) {
    mainClass.set(project.findProperty('mainClass'))
    classpath = sourceSets.main.runtimeClasspath
}

La importancia de esta configuración es hacer explícitas las reglas del viejo mundo. Lo más problemático en proyectos antiguos a menudo no es la falta de capacidad, sino que esa capacidad está oculta en los hábitos. La prueba se ejecuta a través de la entrada main(), el código fuente se coloca en el directorio antiguo y la compilación se escribe asumiendo la ruta en la era Ant. Copilot puede ahorrar tiempo aquí, pero ahorra tiempo de traducción, no tiempo de evaluación.

El tiempo de juicio no se puede subcontratar. Gradle 8 parece más nuevo, Java 17 parece más moderno y saltar directamente también parece más limpio, pero es posible que estas opciones no satisfagan las limitaciones del código fuente antiguo y las pruebas antiguas al mismo tiempo. El mayor temor en la modernización es considerar las actualizaciones de herramientas como un progreso y la ejecución de comandos como una comprensión del sistema. Mientras un proyecto no haya alcanzado la base operativa, las pruebas ecológicas no se consideran una victoria; sólo se puede considerar que no alcanzan la superficie expuesta por el momento.

El enfoque en el que más confío es dividir primero el problema en cuatro niveles: si se puede ejecutar, si se puede editar, si se puede probar y si se puede modificar. El primer nivel es reproducir la escena, el segundo nivel es determinar el puente, el tercer nivel es determinar qué ha guardado la prueba anterior y el cuarto nivel es la refactorización real. Copilot es particularmente útil en los dos primeros niveles. Es adecuado para el trabajo físico siguiendo registros y estructuras de directorios, y para unir pistas fragmentadas en un mapa legible. En el cuarto nivel, el modelo sólo debe ser responsable del transporte y las indicaciones, y las personas deben confiar en otras personas para tomar decisiones.

El resultado más valioso de modernizar el viejo sistema es convertir un montón de cosas que “deberían funcionar” en “cosas que realmente funcionan y sabemos por qué funcionan”. Una vez establecida esta escalera de compatibilidad, el desmantelamiento posterior tendrá ritmo y los cambios tendrán límites. Copiloto es como un asistente en primera línea en este momento, sosteniendo una linterna para observar la edad, la entrada y las dependencias. Lo que realmente determina la dirección es el juicio sobre la historia del viejo sistema.