¿Cómo se puede seguir el desarrollo de grandes sistemas de software (a largo plazo) con el legado y el nuevo código? [cerrado]

Question

Yo trabajo en una gran base de código con una gran base instalada de usuarios. El código fue escrito originalmente en VB6 con unos pocos módulos COM C ++ para el trabajo bajo nivel.

Es totalmente factible volver a escribir todo el código que ya está escrito en Visual Basic 6 y está siendo utilizado por nuestros clientes todos los días, pero también se sigue haciendo mejoras y personalizaciones del software (grandes y pequeños).

Mi solución hasta ahora es escribir la mayor parte del nuevo código en C # (WinForms WPF y hasta ahora) y luego usar interoperabilidad COM para llamar a los módulos de Visual Basic 6.

¿Alguien por ahí tiene experiencia con conjuntos de programas a largo plazo como esta (de 10 años) que no pueden detenerse por una reescritura completa, pero necesitan nuevos desarrollo continuo al mismo tiempo. Además, en los sistemas mixtos de este tipo, ¿cuál es la mejor manera de interconectar los módulos? Estoy utilizando COM en este momento, pero he considerado IPC con procesos separados también.

Answer 1

Es difícil dar una sola respuesta tan abarcadora pero el enfoque de alto nivel es clara. Al menos, este es el enfoque que he usado. Dar prioridad a sus metas y luego tratar de identificar los costos de alcanzar esos objetivos. Sus costos se reducen esencialmente a 'tiempo de desarrollo'.

En primer lugar, usted quiere lo que está trabajando para seguir trabajando. Si usted tiene algo que está trabajando, y no hay una buena razón para volver a escribir, mantenerla.

Si algunos de su código existente necesita una reforma para hacer su trabajo, entonces usted está buscando en los costes de mantenimiento. En este punto es necesario determinar si una reescritura mejorará los costes de mantenimiento suficiente como para merecer la pena. No se olvide de restar las pruebas y la depuración de los nuevos errores, ya que habrá nuevos errores. No descarte el código de trabajo sólo porque es viejo.

Si su código existente es suficientemente modular, por lo general puede hacer mella en él una sola pieza a la vez. Reescribir los componentes de alto mantenimiento en primer lugar.

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

Answer 2

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

¿El código de Visual Basic 6 comprenden objetos COM?

Usted ha mencionado que el código "no puede ser detenido por una reescritura completa". Pero usted no tiene que parar. Uno a uno, se puede reemplazar cada pieza de la funcionalidad de Visual Basic 6 con el código C # equivalentes. Esto permitirá hacer un cambio a la vez (preferiblemente con pruebas automatizadas para demostrar que no ha roto nada).

Answer 3

Re-escribir en función de las necesidades cuando hay un factor de motivación.

Uno de los proyectos de ventanas viejas que tenía trabajado en un motor de reglas escrito en C que estaba trabajando, así que simplemente lo dejó como un archivo DLL cuadro negro.

Hemos construido un nuevo front-end y la base de usuarios estaba impresionados por la facilidad de uso aspecto moderno de la aplicación. Nada en la parte interna había cambiado realmente.

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

Answer 4

Tenemos varios sistemas de este tipo. La parte preocupante de todo esto es la href="http://msdn.microsoft.com/en-us/vbrun/ms788707.aspx" rel="nofollow noreferrer"> estado del soporte del ciclo de vida de VB6 . Existe un riesgo (por pequeño que sea) que no vas a ser capaz de obtener ayuda de Microsoft con un tema sensacional con, por ejemplo una futura actualización del servidor, y no tienen la capacidad de fijar por sí mismo (por ejemplo, debido a incompatibilidades entre el VB6 DLL y el servidor de O / S parcheado). Este es un riesgo que su administración podría estar interesado en - pero entonces, si usted no tiene ningún acuerdo de apoyo ahora, tal vez se sienten cómodos con eso?

En realidad estamos mirando reescritura y el rediseño de algunos de los más críticos. Hemos tratado de evolución gradual, y que puede funcionar, pero lo hace para un (digamos) las operaciones interesantes y situación de mantenimiento. Me gustaría recomendar encarecidamente la instrumentación de todo (código antiguo y nuevo) con un montón de registro configurable, si no está ya, para ayudar con el aislamiento de fallos.

COM suena como una interfaz razonable entre la herencia y el nuevo. A menos que tenga una interacción muy simples entre los componentes, no puedo ver por qué le gustaría volver a un mecanismo más básico IPC. COM tiene sus complejidades, sino que también proporciona una gran cantidad de abstracciones útiles para, por ejemplo, tipos de datos y control de versiones que habría que reinventar y mantener ...

Answer 5

Creo que hay que buscar en sus rutas de actualización para sus clientes. El hecho es que en algún momento cuando tienen 16 CPU de núcleo que va a querer concurrencia para acelerar las cosas. Por lo que tiene un modelo de negocio para alejarse forma VB6 y hacia WCF. WCF ha construido en el soporte de concurrencia y sincronización. Puede ser utilizado para comunicación local en proceso, así como entre procesos y la comunicación transversal a la máquina. También tiene la ventaja de que le permite hacer más programación de estilo de AOP.

Answer 6

Actualmente soy uno de varios desarrolladores que trabajan en un sistema heredado grande que comenzó como una combinación de C y C ++ con Win32 y, más tarde, MFC con un puñado de reunión entre el código extremo C espalda. Hemos saltado recientemente de VC ++ 6 a Visual Studio 2005 (y desde entonces han actualizado a 2008) para la última versión del proyecto que estamos trabajando. Desde la actualización IDE / compilador, hemos estado limpiando algunos de la apariencia y el estado añadiendo manejado C ++ con Windows Forms y ahora C # con WCF.

Si bien los fundamentos de nuestro sistema, incluyendo la parte de atrás, es casi sin duda permanecerá en C (al menos en el futuro previsible), nada nuevo en la parte delantera lo más probable es que hacerse en C # / WCF. Cuando tenemos el tiempo y / o necesidad, tenemos la intención de comenzar a reemplazar partes más antiguas de la parte delantera con un equivalente de código C # / WCF.