Mucha gente cree que COBOL es un antiquísimo lenguaje de programación que ya nadie usa, pero la realidad es que hay aún muchos sistemas que usan cotidianamente este lenguaje. La razón de esto es que muchos sistemas se escribieron en COBOL, particularmente para el mundo financiero y en muchas ocasiones es más fácil adecuarlos a las nuevas necesidades que escribir un nuevo programa en otro lenguaje. De hecho, hay en la red mucha información de COBOL y no podemos considerarlo como un lenguaje muerto.
Aquí hablaremos de la experiencia de migrar una aplicación para manejar la entrega de periódicos (de The New York Times) a un nuevo lenguaje. El sistema que usa el periódico es de IBM y data de 1979, pero la modernización casi obligatoria requiere incrementar la interoperabilidad con otros sistemas así como reducir los costos de operación.
Y aunque un sistema de control de los envíos de periódicos no parece ser un asunto muy complicado, se tiene una aplicación que ha crecido a dos millones de líneas de código en COBOL, en donde se factura, se lleva control de los cuentahabientes y de las rutas para la entrega del periódico. Un intento de re-desarrollar esta aplicación se hizo entre el 2006 y el 2009, pero fracasó. El nuevo plan ahora es empezar de cero y entregar un sistema “de equivalencia funcional”.
Esto se hizo poniendo juntos los conjuntos de componentes relacionados para desarrollar un subconjunto de la aplicación principal. El grupo de componentes podría ejecutarse y probarse como si fuese una “caja negra” a través de las interfaces accesibles externamente, como SOPA Web Services, tablas de datos y archivos.
“Dados los mismos datos de entrada, la salida del grupo de componentes heredado se comparó con la salida de las partes modernizadas. Cuando estas eran iguales, la prueba se consideraba que había sido exitosa. En caso contrario lo que se haría es encontrar el origen de esa no-coincidencia en los datos”. Y aunque sonaba todo muy sencillo en teoría, en la práctica fue mucho más complicado.
“La vasta mayoría de los componentes heredados en las aplicaciones no tienen el suficiente nivel de pruebas para codificar la información que se requiere para hacer la prueba de funcionalidad equivalente. Como consecuencia, mucho tiempo se intentó analizar las entradas, salidas e incluso el comportamiento de los componentes cuando fallaron las pruebas y el buscar la razón de esto. Esto fue particularmente una tarea en la que se llevó mucho tiempo, sobre todo para los trabajos en batch que significaban muchas horas-hombre”.
El proceso de re-escribir el código llevó un año, pero se juzgó como “exitoso” incluso a pesar de un par de “problemas en la producción”. El desarrollador dijo: “la aplicación modernizada se demostró como muy estable en producción en los últimos ocho meses y el periódico se sigue entregando diariamente sin problemas”.
Quienes desarrollaron el nuevo sistema indicaron que el desarrollo de nuevas características se mantiene como un reto. Se requiere de conocimiento de las diferentes versiones de COBOL y dde conceptos sobre mainframes que los ingenieros de Java no tienen. Los desarrolladores del mainframe en COBOL tienen los conceptos, pero no son muy avezados en Java. El equipo ahora está entrenando de manera cruzada a sus desarrolladores con la esperanza de que esto ayude con la transferencia de conocimiento. Cabe señalar que se encontraron dificultades para reclutar programadores de Java que quisieran portar la aplicación porque simplemente no les era suficientemente atractivo.
La entrada El camino de COBOL a Java en lenguaje de programación se publicó primero en unocero.
