¿Cómo continúa desarrollando sistemas de software grandes (a largo plazo) con código heredado y nuevo?

Question

Trabajo en una gran base de código con una gran base de instalación de usuarios. El código fue escrito originalmente en vb6 con algunos módulos COM de C++ para el trabajo de bajo nivel.

Es completamente inviable reescribir todo el código que ya está escrito en vb6 y que nuestros clientes lo utilizan todos los días, pero también seguimos realizando mejoras y personalizaciones para el software (grandes y pequeños).

Mi solución hasta el momento es escribir la mayor parte del código nuevo en C# (winforms e incluso wpf ahora) y luego usar la interoperabilidad COM para llamar a los módulos desde vb6.

¿Alguien por ahí tiene experiencia con paquetes de software a largo plazo como este (más de 10 años) que no se pueden detener para una reescritura completa, pero necesitan un nuevo desarrollo continuo al mismo tiempo. Además, en sistemas mixtos como este, ¿cuál es la mejor forma de interconectar los módulos? Estoy utilizando COM en este momento, pero también he considerado el IPC con procesos separados.

Answer 1

Es difícil dar una sola respuesta que abarque todo, pero el enfoque de alto nivel es claro. Al menos, este es el enfoque que he usado. Dé prioridad a sus objetivos y luego trate de identificar los costos para alcanzar esos objetivos. Sus costos básicamente se reducirán a 'tiempo del desarrollador'.

En primer lugar, desea que todo lo que esté funcionando funcione. Si tiene algo que está funcionando, y no hay una buena razón para reescribirlo, guárdelo.

Si parte de su código actual necesita una actualización para hacer su trabajo, entonces está buscando los costos de mantenimiento. En este punto, debe determinar si una reescritura mejorará los costos de mantenimiento lo suficiente como para valer la pena. No se olvide de restar las pruebas y la eliminación de fallas de nuevos errores porque habrá nuevos errores. No descarte el código de trabajo solo porque es antiguo.

Si su código actual es lo suficientemente modular, por lo general puede eliminarlo de una pieza a la vez. Reescriba primero los componentes de alto mantenimiento.

Si va a hacer un nuevo desarrollo en C#, entonces debería estar bien trabajando con componentes COM hasta que tenga suficiente justificación para reemplazarlos.

Answer 2

Creo que necesita ver sus rutas de actualización para sus clientes. El hecho es que en algún momento cuando tienen 16 CPUs centrales, querrás concurrencia para acelerar las cosas. Entonces tienes un caso de negocios para alejarte de VB6 y hacia WCF. WCF ha incorporado soporte de simultaneidad y sincronización. Se puede utilizar para comunicación local en proceso, así como para comunicación entre procesos y entre máquinas. También tiene el beneficio de permitirle hacer más programación de estilo AOP.

Answer 3

Creo que tienes un buen plan. Esto eventualmente moverá la mayor parte del código a C#, aprovechando el mejor conjunto de herramientas.

¿El código VB6 comprende objetos COM?

Mencionó que el código "no se puede detener para una reescritura completa". Pero no tienes que parar. Uno por uno, puede reemplazar cada pieza de la funcionalidad VB6 con el código C# equivalente. Esto le permitiría hacer un cambio a la vez (preferiblemente con pruebas automáticas para demostrar que no ha roto nada).

Answer 4

Reescriba en caso de necesidad cuando haya un factor de motivación.

Un viejo proyecto de Windows en el que trabajé tenía un motor de reglas escrito en C que funcionaba, así que lo dejamos como DLL de caja negra.

Construimos un nuevo front-end y la base de usuarios quedó impresionada por el nuevo aspecto moderno y fácil de usar de la aplicación. Nada en el interior realmente había cambiado.

La capa de acceso a la base de datos utilizaba DBLIB de SQL Server y no se volvió a ejecutar hasta que actualizamos SQL Server.

Answer 5

Actualmente soy uno de varios desarrolladores que trabajan en un sistema heredado de gran tamaño que comenzó como una combinación de C y C++ con Win32 y, más tarde, MFC con un ensamblaje complejo entre el código C de fondo. Recientemente hemos pasado de VC++ 6 a Visual Studio 2005 (y desde entonces nos hemos actualizado a 2008) para la última versión del proyecto en el que estamos trabajando. Desde la actualización de IDE/compilador, hemos estado limpiando parte del aspecto y hemos agregado C++ administrado con WinForms y ahora C# con WCF.

Si bien los apuntalamientos de nuestro sistema, incluido el back-end, permanecerán casi definitivamente en C (al menos en un futuro previsible), cualquier cosa nueva en el extremo delantero se realizará en C#/WCF. Cuando tengamos el tiempo y/o la necesidad, tenemos la intención de comenzar a reemplazar partes anteriores de la parte delantera con el código C#/WCF equivalente.

Answer 6

Tenemos varios sistemas de este tipo. La parte inquietante de todo esto es el lifecycle support status of VB6. Existe un riesgo (no importa cuán pequeño) de que no pueda obtener ayuda de Microsoft con un problema destacado, como p. Ej. una futura actualización del servidor, y no tendrá la capacidad de solucionarlo usted mismo (por ejemplo, debido a incompatibilidades entre las DLL VB6 y las O/S del servidor parcheado). Este es un riesgo que podría interesar a su administración, pero luego, si no tiene ningún acuerdo de soporte ahora, ¿tal vez se sienten cómodos con eso?

Estamos buscando reescribir y rediseñar algunos de los más críticos. Hemos intentado la evolución incremental, y puede funcionar, pero crea una situación (digamos) interesante de operaciones y mantenimiento. Recomiendo instrumentar todo (código antiguo y nuevo) con un montón de registro configurable, si no lo está ya, para ayudar con el aislamiento de fallas.

COM suena como una interfaz razonable entre legado y nuevo. A menos que tenga interacciones muy simples entre los componentes, realmente no puedo ver por qué le gustaría volver a un mecanismo de IPC más básico. COM tiene sus complejidades, pero también proporciona una gran cantidad de abstracciones útiles para, p. data typing y versioning que tendrías que reinventar y mantener ...