refactoring - Reescribir el código heredado

cobol legacy (17)

Mantendría el código anterior y le agregaría nuevas funcionalidades usando algunas de las mejores cosas de Microfocus / AcuCOBOL. Puede hacer aplicaciones de GUI y llamar a .NET y Java directamente desde su código "heredado".

¿Por qué romper el back-end si funciona para usted? Mantener el back-end funcional y reemplazar el front-end cansado es la solución para la que la empresa para la que trabajo está empezando a emplear.

Así que supongo que mi elección sería la opción n. ° 3, porque hay una solución por el estilo.

Actualmente, mi departamento se enfrenta a la responsabilidad de mantener una base de código COBOL bastante grande. Nos preguntamos cómo agregar nuevas funciones para estar al día con las necesidades del negocio. Los programadores de COBOL son difíciles de encontrar hoy en día, y también creemos que obtendremos una mayor productividad al usar un lenguaje más moderno como Java o C #.

Creemos que tenemos cuatro opciones:

Reescribe todo desde cero, dejando la aplicación anterior en sí misma hasta que esté lista para ser reemplazada
Reescriba todo desde cero, haciendo que algunas personas mantengan la aplicación anterior para hacer frente a las nuevas necesidades comerciales a medida que se construye la nueva.
Escriba todas las nuevas funcionalidades en un lenguaje moderno y encuentre la forma de integrar el nuevo código con la funcionalidad anterior.
Sigue manteniendo la aplicación anterior.

¿Cuál considera que es la mejor opción para nosotros y por qué?

Honestamente, habiendo ayudado a "portar" una aplicación de ColdFusion 5 a PHP a ColdFusion 8, yo diría que vaya con # 1. Deje la aplicación anterior en su lugar y congele el desarrollo. Reúnase con el cliente y especifique cuáles son las nuevas características, además de cómo funciona el viejo sistema / se suponía que funcionara y produzca un buen documento de requisitos. Eso solo deja los detalles de construcción y diseño, que luego puede elegir inteligentemente el mejor idioma y plataforma para su aplicación.

Donde trabajo ahora, en realidad estamos manteniendo una antigua aplicación de CF mientras construimos la aplicación .NET de reemplazo. ¿Te imaginas el código que los chicos de .NET van a tener que escribir después de terminar la aplicación base? Es por eso que recomiendo congelar el desarrollo.

Las opciones n. ° 2 y n. ° 3 son sus mejores opciones. Si su aplicación COBOL almacena sus datos en una base de datos SQL o en algún otro formato, puede acceder fácilmente desde un lenguaje moderno que es la solución más barata / más fácil.

De lo contrario, sería necesario contar con alguien en el personal para implementar nuevas funciones críticas mientras reconstruye. Pero aún sugeriría pedirles a todos que limiten las características nuevas en la antigua base de códigos a solo las verdaderamente críticas.

Mantener COBOL, en el largo plazo, solo va a ser más difícil. Cuanto más espere, más difícil será.

Migra la aplicación gradualmente?

¿Hay alguna forma de que pueda interconectar otro código con el COBOL y reescribir gradualmente los componentes a medida que pasan los cambios? Puede que nunca te deshagas de todo, ¿pero realmente importa?

Reescribir el código existente generalmente es una mala idea. Será muy arriesgado (p. Ej., Se corre el riesgo de romper una funcionalidad poco comprendida en la que alguien confía) y se gastará mucho tiempo sin lograr nada útil que sea visible para la mayoría de los interesados.

No asuma que un programador competente no podrá aprender COBOL si surge la necesidad, un lenguaje de programación es muy parecido a otro. Si contrata a alguien competente en (digamos) C ++ o Java, podrá aprender COBOL.

Otra solución podría ser:

Traduzca el código a un idioma moderno de su elección.

Por lo general, eso implicaría varios trozos grandes:

Reescribe partes de la aplicación heredada que no se pueden traducir. Al menos, use constructos de programación estructurados en todas partes.
Implemente una DSL interna que haga más fácil mapear construcciones del lenguaje antiguo en el nuevo idioma.
Implemente un traductor de código fuente desechable para el 90% del código.
Traduce el 10% restante del código complicado a mano.
Dedique mucho tiempo a compilar la maldita cosa.
Haga que todo se someta a pruebas y arreglos serios.
Lentamente limpie el animal resultante para hacerlo idiomático.

La principal ventaja de este enfoque es que preservará todos los casos desagradables de esquina de negocio que se han codificado a lo largo de los años en la base de código. El gran problema con las reescrituras desde cero es que descartan todo este conocimiento acumulado.

Otra ventaja es que convierte un problema molesto (mantener una aplicación Cobol) en un problema divertido (traducción automática de idiomas), por lo que tiene la oportunidad de involucrar a un buen programador en el proyecto.

Comentario de Jim Denver
¿No será muy difícil escribir un traductor que se traduzca en un código que sea legible y fácil de mantener? Nuestro problema es que la aplicación COBOL es una pesadilla de mantenimiento. No queremos que esto se convierta en la misma pesadilla en otro idioma.

No puedo decir lo difícil que será. Es más fácil si el código que está comenzando es regular. Pero en cualquier caso, terminará con "COBOL escrito en $ LANG". Este es solo un punto de partida para las reescrituras incrementales hasta que se solucione la pesadilla de mantenimiento.

Esta es solo una alternativa para "reescribir desde cero" y "mantener en COBOL". Puede ser que el valor del conocimiento acumulado en la base de código sea menor que el costo esperado de una limpieza incremental.

Soy un firme partidario de actualizar las aplicaciones heredadas a tecnología de vanguardia (para consternación de mi gerente). Esto siempre debe ser un enfoque por etapas y solo debe llevarse a cabo si es necesario. Intente mantener la aplicación heredada ejecutándose y cumpliendo su propósito, pero cree partes pequeñas de la misma en una tecnología más nueva, y con el tiempo elimine gradualmente el código anterior y reemplácelo por uno más nuevo. Siempre me aseguro de priorizar estos en beneficio / costo para el negocio primero.

Si la aplicación está muy entrelazada, parece que necesita contratar algunos scripters COBOL para ayudar a sacar los servicios aislados, para que pueda privarlos cuando esté listo.

Tenga en cuenta esto: a veces los errores y peculiaridades en el código heredado original cumplen una función en la que se basa la empresa, así que tenga cuidado de corregir errores de los que luego se basa otro código.

Tenga cuidado al intentar una reescritura completa. Hay muchos ejemplos de que esto está fallando para muchas compañías de software. Netscape es un buen ejemplo

admitidamente, el problema involucra a cobol, que hace que cualquier respuesta sea específica para tus necesidades, si dijiste "tenemos una aplicación VB antigua" o una aplicación C antigua, entonces la opción 3 siempre es la correcta.

He trabajado en 3 compañías que decidieron ir por la opción # 2. 2 se fue a la quiebra tratando de pagar por el nuevo sistema, mientras que solo obtenía ingresos de los antiguos, el tercero llegó muy cerca de hecho.

El otro factor de la operación n. ° 3 es que puedes mantener todas las viejas correcciones de errores que has cometido a lo largo de los años. Cada reescritura siempre presenta más y más errores, en parte porque querrás que la reescritura se realice rápidamente, en parte porque la escribirás en un idioma nuevo y desconocido, y en parte porque todo el código nuevo tiene errores.

Refactorice y reemplace los fragmentos lógicos de la aplicación anterior, eventualmente tendrá una nueva y brillante. Comience con la GUI para obtener el enfoque más seguro para el nuevo. Además, cuando hayas terminado de reescribir la aplicación en algo nuevo, algo más nuevo será lo más genial y tu nueva aplicación quedará obsoleta y ¡volverás a publicar la misma pregunta otra vez!

Mantendría la aplicación anterior, pero luego, soy un programador de cobol ...

Esta es una variación de la Opción 3:

Microfocus proporciona una herramienta llamada Enterprise Server que permite a COBOL interactuar con servicios web.

Si tiene un programa COBOL A y otro programa COBOL B y A llama a B a través de la sección de interfaz, la herramienta le permite exponer la sección de interfaz de B como un servicio web.

Para el programa A, a continuación, genera un proxy de cliente y A ahora puede llamar a B a través de un servicio web.

Por supuesto, como B ahora tiene un servicio web, cualquier otro tipo de programa (línea de comando, aplicación de Windows, Java, ASP, etc.) ahora también lo puede llamar.

Usando este enfoque, puede "picar en los bordes" para mover la GUI a un enfoque moderno basado en navegador usando algo como ASP mientras sigue utilizando el motor de negocios COBOL.

Y una vez que tenga un conjunto decente de servicios web, estos pueden ser utilizados para cualquier nuevo desarrollo que proporcione una forma de alejarse de COBOL a largo plazo.

¿Qué pasa con el uso de una de las aplicaciones de terceros que toman cobol y lo convierten a C # como:

http://www.softwaremining.com/index.jsp

O portándolo a COBOL.net, eso debería ser más fácil, entonces todo lo que agregue podría estar en uno de los otros lenguajes .net.

Insuficiente información para determinar el rumbo correcto.

Aunque mucha gente ha respondido con respuestas apropiadas dadas circunstancias particulares, la respuesta correcta realmente depende de la situación comercial de su empresa.

Cosas como roadmaps existentes, compromisos de entrega, contratos de servicio, lanzamiento de nuevas características de tiempo requerido y similares determinarán qué es lo mejor en su situación.

Dicho esto, la respuesta de muchos tecnólogos será # 1, mientras que la respuesta de muchos empresarios será # 4. Al no saber nada más de lo que se presentó, empujaría al equipo a investigar profundamente el # 3 ya que probablemente sea el riesgo más bajo. El # 1 tiene un historial comprobado de falla, y el # 2 es simplemente el # 1 con menos recursos. # 4 probablemente no sea una solución a largo plazo, A MENOS QUE usted esté EOL''ing esta línea de productos en el corto / mediano plazo.

Lo bonito de COBOL es que los requisitos de datos se detallan justo en la parte superior del código. También ayuda que COBOL se diseñó para escribirse utilizando (relativamente) inglés de NEGOCIOS sencillo (no es necesario que se apliquen los TXTSPK).

Por supuesto, si su cortacésped es más antiguo que algunos de sus programadores, olvídese de que lean la fuente. Ellos solo lloriquearán demasiado.

Una compañía que conozco luchó con exactamente la misma pregunta durante muchos años; finalmente, abandonaron la aplicación COBOL y cambiaron a SAP. Hacer eso fue un gran proyecto que tardó varios años en completarse, pero funcionó bien.

Obedece la regla 80/20. Siéntese con el cliente y escriba las especificaciones para el 20% de la aplicación que obtiene el 80% del uso. Escribe eso en un sistema moderno. Luego, mantenga el sistema anterior para reducir el número de casos especiales o elimínelo gradualmente a medida que desarrolla un nuevo sistema.

No intente reescribir el código anterior al 100%. Eso es tonto. El mejor escenario posible es que tenga un puerto completo de un sistema obsoleto. En el peor de los casos, quema mucho tiempo y dinero para tener un nuevo sistema fallido y todavía está atascado con el sistema anterior.

Use el tiempo y el esfuerzo para mejorar el sistema, no solo para portarlo. Después de portar las partes más importantes, use el tiempo para volver a considerar los casos especiales.

Hice una migración de un sistema antiguo a uno nuevo (aunque fue en una escala mucho menor).

Utilizamos con bastante éxito el enfoque de "reemplazo gradual" (n. ° 2) para un sistema de cliente / servidor (un sistema de informes escrito por el propio propietario). De hecho, lo hicimos con un giro, utilizando un enfoque de "aproximación":

Primero implementamos un nuevo servidor que ofrecía toda la funcionalidad / interfaz de llamada del servidor anterior, pero internamente solo delegaba todo en el servidor anterior, que se mantenía ejecutándose.
Luego todos los clientes fueron cambiados al nuevo sistema; esto fue relativamente indoloro ya que el nuevo sistema era esencialmente solo un envoltorio.
Finalmente, reescribimos gradualmente el nuevo servidor para implementar la funcionalidad sin volver a llamar al sistema anterior.

Este enfoque dio mucha flexibilidad y permitió implementar cosas nuevas sin tocar el código anterior. El cambio duró más de un año, y las últimas partes de la aplicación solo se migraron al nuevo sistema porque el antiguo servidor se estaba ejecutando en un hardware dedicado y obsoleto que debía ser liberado.

De hecho, fui a la sala de servidores para cerrar personalmente el servidor anterior cuando todo se migró. Eso fue divertido :-).

Incidentalmente, este enfoque de "cambio gradual" también nos permitió implementar algunos registros en el nuevo sistema, para decidir qué funcionalidad se usó con qué frecuencia. De esta forma, algunas de las antiguas funcionalidades del servidor podrían eliminarse, ya que resultó que los clientes ya no las usaban. Esa fue una ventaja significativa del enfoque "proxying".

Si usa OpenVMS, BridgeWorks puede ayudarlo a crear una aplicación web usando su código anterior con modificaciones menores.