Reescribir el código heredado

Question

Mi departamento se enfrenta actualmente a la responsabilidad de la tarea 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#.

Nos sentimos que tenemos cuatro opciones:

1. reescritura de todo desde cero, dejando la antigua aplicación a sí mismo hasta que esté listo para ser reemplazado
2. todo reescritura desde cero, consiguiendo algunas personas para mantener la aplicación antigua para hacer frente a las nuevas necesidades comerciales a medida que se construye la nueva
3. Escriba todas las nuevas funcionalidades en un lenguaje moderno y encuentre la manera de integrar el nuevo código con la funcionalidad anterior.
4. Mantenga el mantenimiento de la aplicación anterior.

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

Answer 1

Honestamente, habiendo ayudado a "portar" una aplicación de ColdFusion 5 a PHP a ColdFusion 8, 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 desarrollamos la aplicación de reemplazo .NET. ¿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.

Answer 2

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

Answer 3

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, a la larga, solo va a ser más difícil. Cuanto más espere, más difícil será.

Answer 4

Creo firmemente en la actualización de las aplicaciones heredadas a la 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, de modo que puede privarlos cuando esté listo.

Nota esto: a veces los errores y peculiaridades en el código heredado originales sirven a un propósito que el negocio se basa en, así que ten cuidado con los errores de fijación que otro código se basa más adelante.

Answer 5

admiteddly, el problema consiste en COBOL que hace que cualquier respuesta específica a sus necesidades, si usted dijo "tenemos un viejo VB aplicación" o aplicación C de edad, a continuación, la opción # 3 es siempre el camino correcto a seguir.

He trabajado en 3 compañías que decidieron optar por la opción 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 para la operación n. ° 3 es que consigues 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.

Refabrica y reemplaza los trozos lógicos de la aplicación anterior, con el tiempo obtendrás uno nuevo 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!

Answer 6

Obedezca 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 volver a escribir el código anterior 100%. Eso es una tontería. 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.

Utilice 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.

Answer 7

Otra solución podría ser:

traducir el código de un lenguaje moderno de su elección.

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

• partes de reescritura de la aplicación de legado que no se puede traducir. Al menos, use constructos de programación estructurados en todas partes.
• Implemente un internal DSL que hace que sea más fácil mapear constructos del idioma 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 engañoso a mano.
• Pasar un montón de tiempo compilando la maldita cosa.
• Obtenga todo el asunto a través de algunas pruebas y arreglos serios.
• Lentamente limpie el animal resultante para hacerlo idiomático.

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

Otra ventaja es que resulta un problema molesto (el mantenimiento de una aplicación COBOL) en una diversión un problema (traducción de idiomas automatizado), por lo que tiene una oportunidad de conseguir un buen programador comprometido con el proyecto.

El comentario de Jim Denver

¿No será muy difícil escribir un traductor que se traducen en código que es algo 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.

Esto 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.

Answer 8

Migra la aplicación gradualmente?

¿Hay alguna forma de que pueda conectar otros códigos al COBOL y reescribir gradualmente los componentes a medida que los cambios pasan? Puede que nunca te deshagas de todo, ¿pero realmente importa?

Reescribir el código existente es generalmente una mala idea. Será muy arriesgado (por ejemplo, romper el riesgo de una funcionalidad poco conocida en la que alguien confía) y consumir 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.

Answer 9

Me mantengo la aplicación antigua, pero entonces, yo soy un programador COBOL ....

Answer 10

Me gustaría mantener el viejo código y añadir nuevas funcionalidades a él utilizando algunas de las grandes 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.

Answer 11

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

Microfocus proporcionar una herramienta llamada Enterprise Server que permite COBOL para interactuar con servicios web.

Si tiene un programa COBOL A y otro programa COBOL B y A llama 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 se 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.

Answer 12

¿Qué pasa con el uso de uno de los terceros Parte aplicaciones que tienen COBOL y la convierten en C# como:

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

O portarlo a COBOL.net, que debería ser más fácil, entonces todo lo que podía añadir estar en uno de los otros lenguajes .net.

Answer 13

Lo bueno 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 lea la fuente. Ellos solo lloriquearán demasiado.

Answer 14

Datos insuficientes para determinar el rumbo correcto.

Aunque muchas personas han intervino con respuestas apropiadas dadas las circunstancias particulares, la respuesta correcta en realidad depende de la situación del negocio en su empresa es.

Cosas como planes de trabajo existentes, los compromisos de entrega, contratos de servicio, el tiempo-a required-launch-of-new-features, 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ó, presionaría al equipo para que investigara 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.

Answer 15

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.

Answer 16

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

Answer 17

He realizado la migración de un sistema anterior a uno nuevo (aunque fue a una escala mucho menor).

Utilizamos con bastante éxito el enfoque de "reemplazo gradual" (n. ° 2), para un sistema cliente/servidor (un sistema de informes pequeño y escrito por el propio departamento).En realidad no es con un giro, mediante el uso de un enfoque de "proxy":

• Primero implementó un nuevo servidor que ofreció toda la interfaz de funcionalidad/llamada del servidor antiguo, pero internamente simplemente delega todo para el antiguo servidor , que se mantuvo funcionando.
• Luego todos los clientes se cambiaron 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 brindaba mucha flexibilidad y permitía 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 servidor anterior se estaba ejecutando en un hardware antiguo y dedicado que debía ser descomisionado.

De hecho, fui a la sala del servidor 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 utilizó 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".