.net vb6 vb6-migration

Cómo migrar código VB6 feo y no documentado a.NET



vb6-migration (9)

¿Es absolutamente necesario migrar el código? Si no lo hace, sigue cumpliendo su propósito, y se puede mantener a medias, solo déjalo en paz y sigue adelante .

Su motivación para mover el código a un nuevo idioma pronto se desvanecerá después de innumerables horas, semanas y meses de migración del código, especialmente en la escala que mencionó.

La idea de la migración de código es una idea fantástica, conceptualmente. Con toda probabilidad, es un desastre terrible y odiarás la vida haciéndolo.

Piénsalo, ¿odias tu vida ahora mientras arreglas un defecto? Escalate eso por 100x para el proyecto de migración.

La mayoría de las empresas realmente podrían preocuparse menos por lo que está bajo el capó mientras funcione. Recuerde, no son desarrolladores, no les importa lo difícil que sea arreglarlo (ya que no son ellos quienes lo hacen) y motivan a la empresa a gastar decenas de miles de dólares para traer código actualizado, simplemente no tiene ningún sentido comercial.

Sé que ya hay preguntas sobre la migración de VB6, pero la base del código de mi proyecto trae algunas preguntas nuevas aquí.

Debo decir que la calidad, estructura y arquitectura del Código es solo una pesadilla. Hay 2 grandes proyectos: Nr.1 ​​con 40 formularios, 40 módulos y algunos archivos de clase, este EXE es una especie de "sistema base". Nr.2 con 80 formularios, 20 módulos y algunos archivos de clase nuevamente, estas funciones de llamadas EXE forman el "sistema base". Luego hay ~ 10 otros proyectos con GUI (1-3 formularios cada uno) y otros 90 proyectos que no son GUI, la mayoría de ellos archivos EXE, algunos DLL. Los DLL están escritos en C, C ++ y VB6.

El Código ha crecido evolutivamente desde hace 10 años, y está escrito principalmente por 1 (mal) desarrollador a la vez.

  • Las funciones con 500 líneas (y más) son muy comunes.
  • El 90% de los componentes de la GUI se denominan texto1, comando2 (1), ...
  • copiar y pegar está en todas partes, por ejemplo, se copió un proyecto EXE (sin GUI) con 5000 líneas de código y el único cambio en la copia fue enviar archivos por Correo en lugar de FTP (también hay 2 copias más del mismo proyecto) ).
  • Una vez tuve un formulario pequeño (15 campos), donde debería resolver un problema pequeño (normalmente, media hora), cada vez que cambiaba algo, no funcionaba o producía nuevos errores en el formulario. Después de 2 días, decidí volver a escribir el formulario completamente y de ~ 20 declaraciones SQL en el formulario antiguo, solo 2 sobrevivieron en el nuevo.
  • Ni siquiera preguntes sobre los comentarios en el código ...

Me hice cargo del proyecto hace unos meses y soy el único mantenedor. Existe un flujo constante, (pero bajo) de Solicitudes de Cambio y errores, y recibimos un presupuesto de mantenimiento de nuestros clientes para mantener el software en funcionamiento y "actualizado" en términos de requisitos legales.

Mis opciones

1) Reescribir desde cero: en ese caso, podría escribirlo en Java para portabilidad. El problema aquí es que además de la ayuda (antigua) del usuario, no hay documentación, por lo que el código feo es la "documentación". Hay una persona que tiene el nivel alto de saber cómo debe hacer el software. Además, es difícil convencer a la administración de hacerlo, incluso si a largo plazo hay grandes ahorros en los costos, hay problemas políticos. Tampoco puedo hacer ese proyecto (vb) a la vez porque la estructura de la base de datos no es mejor que el código, es decir, también tiene que hacerlo desde cero. Así que solo puedo cambiar todo el software a la vez.

2) Primero migre el código a VB.NET / C # Migración de los proyectos principales, ya lo probé y obtuve ~ 2000 comentarios de actualización del Proyecto Nr.1, la mayoría de ellos cosas como Screen.MousePointer cambiado, funciones con valores de retorno variables y pronto. Mi idea aquí es después de la conversión, crear clases para la abstracción de base de datos, cambiar el código para usar estas clases y refactorizar, migrar y cambiar los otros proyectos también y cuando todo el código use las clases de base de datos, cambie la estructura de la base de datos.

3) Refactorice el código en VB6 siempre que tenga que cambiar algo allí de todos modos (ya lo estoy haciendo en parte) y en algún punto refactorizar también el resto. De esa manera es más fácil ver la funcionalidad original, porque es un código original y cuando hay errores, es obvio que no pueden ser resultados de la migración. Cuando el código es refactorizado (supongo que será un 50-75% más pequeño que el otro), es más fácil migrarlo a .NET. Luego cambie la estructura de la base de datos (y luego haga otra ronda de refactorización ...).

Hay algunos cambios más importantes que hacer en el futuro (hacerlo compatible con Win7 y otro CR grande que afecta a grandes partes del código), por lo que sería una buena oportunidad para hacer estos cambios, ya que tendré que hacerlo. Mucho del código de todos modos.

Mi pregunta es: ¿quién tiene experiencia / sugerencias para migrar código malo y feo? ¿Qué opciones sugerirías?

A partir de su descripción de este proyecto, parece que podría ser posible refactorizar y migrar al mismo tiempo. Está claro que tomará la gran cantidad de código redundante y lo consolidará; es probable que, como parte de la consolidación, también pueda reescribirlo (el código redundante, es decir) en .NET.

Esto no funcionará para cosas de UI. Pero lo hará para bases de datos y lógica de negocios. Por ejemplo, no he visto su código, pero apostaré a doblar el dinero que la mayoría de los cuadros combinados de su aplicación se rellenan con métodos en su forma (probablemente se copian y pegan en Form_Load ) que crean conjuntos de registros ADO y los recorren. Eso es algo que puede ser refactorizado en una clase de acceso a datos .NET e integrado en formas existentes con facilidad. Probablemente, también le permitirá introducir el mundo mágico del almacenamiento en caché en esta aplicación, lo que será agradable porque probablemente resultará en mejoras visibles del rendimiento.

Y las mejoras visibles son importantes. A menos que su administración comprenda completamente la necesidad de hacer esto, este es un esfuerzo de muy alto riesgo. Es muy malo si se encuentra diciéndole a su gerencia que un CR dado tardará más en implementarse de lo que esperan debido a problemas en su refactorización. Incluso si tiene soporte completo, no desea que surja esta situación, pero es mucho peor si su apoyo es parcial. Las mejoras visibles harán mucho para mitigar esto.

Además, existe una creciente bibliografía sobre el problema de la refactorización del código heredado. Necesitas estar encima de eso. Cuanto más sepa antes de sumergirse en esto, mejor será su experiencia. No he leído el libro de Michael Feathers, pero si estuviera en tu lugar, es lo primero que haría.

Código de 14 años migratorio similar experimentado a VS2008

Aquí hay algunos consejos:

  1. Eliminar dependencias en componentes de terceros.
  2. Considere la migración por etapas, por ejemplo, utilizando interoperabilidad inversa.
  3. Los colores y las fuentes deben tratarse a mano.
  4. Tenga cuidado con los objetos sin inicializar en matrices después de la migración a .NET
  5. Cambie en error para intentar atrapar
  6. Utilice el espacio de nombres Microsoft.VisualBasic.Compatibility.VB6 donde sea necesario.
  7. Mantenga la refactorización al mínimo hasta que todo el código se convierta a .NET
  8. Tenga cuidado con los arreglos que no sean cero en su código VB6.
  9. Refactorice (minimice) su código en VB6 para que pueda pasar por el asistente de conversión de código.
  10. Tenga cuidado con los controles VB6 basados ​​en 1, por ejemplo, ListView
  11. Utilice synclock para evitar problemas de subprocesos.
  12. Si está haciendo el refactor manual de un sub, tenga cuidado con los cambios en el tamaño de los tipos de datos, especialmente si está trabajando con el archivo IO.

Hay una compañía que puede ayudarlo con todo el proceso (aunque no los usamos) http://www.vbmigration.com/

Después de haber trabajado en varios proyectos de migración, lo primero que debe hacer es tener claro cuáles son sus objetivos de migración. Estos pueden variar significativamente de una organización a otra, pero ayudan a establecer prioridades durante el proyecto de migración real. También ayuda a evaluar mejor los beneficios contra los riesgos y costos.

Como han mencionado otros, es importante darse cuenta de que el proceso de migración no mejorará automáticamente la calidad del código. Entonces, si su objetivo principal es refactorizar (y nada más), debe tener en cuenta que pueden pasar semanas o meses antes de tener un código funcionalmente equivalente (según el tamaño del código y la complejidad de la migración).

Dicho esto, .NET tiene algunas herramientas muy buenas para refactorización y análisis de código, además de conjuntos de pruebas de unidad. Las herramientas de conversión automatizadas como el Visual Basic Upgrade Companion de ArtinSoft se pueden personalizar para hacer cumplir los estándares de codificación o mejorar el código significativamente durante la conversión. Esta ReSharper con otras herramientas de modificación de código como ReSharper acelerará enormemente su transición a .NET.

En mi experiencia, un proyecto de migración es un proyecto manejable, siempre y cuando sepa que hay un esfuerzo manual involucrado. Las herramientas comerciales tienen modos de evaluación que pueden ayudar a cuantificar el esfuerzo de migración y darle una idea de los desafíos que podría enfrentar en una migración.

Si prefiere una solución de bajo riesgo y costo, me limitaré a refactorizar el código con miras a una eventual migración. He tenido clientes para quienes este enfoque funcionó. Así que cuando llegó el momento de migrar su código, varias cosas ya se habían resuelto.

Básicamente, cualquier nuevo control personalizado debe escribirse en .NET y exponerse como controles ActiveX para ser utilizados por la aplicación VB6. Del mismo modo, las nuevas funciones de DLL se deben colocar en ensamblados .NET que se pueden usar a través de COM. De esa manera, cuando llegue el momento de migrar, no tendrá que preocuparse por esos controles o bibliotecas.

En comparación con algunas de las cosas en las que he trabajado, suena bastante pequeño. Sin embargo, existe otro enfoque que funcionará en conjunto con el que se muestra arriba en PeanutPower.

La respuesta es crear un marco que le permita cortar secciones del programa a la vez y convertirlas una por una.

por ejemplo, inserte una "capa" de adaptador de base de datos que maneje todas las llamadas a la base de datos, luego una por una, elimine cada una de las secuencias de SQL y reemplácela por una llamada a la capa db. Las llamadas antiguas seguirán dirigiéndose mientras que las llamadas nuevas pasan por la capa. Finalmente, todas las llamadas pasarán por la capa y podrá cambiar la base de datos de back-end.

Puede hacer lo mismo con cualquier otra sección del código al expandir la capa de marco para cubrir esa funcionalidad.

La clave para cambiarlo de VB6 a VB.NET (por ejemplo) es usar la biblioteca Interop, aquí hay un artículo: http://support.microsoft.com/kb/817248

Otro, mucho más tarde, pensó: Obtenga MZ-Tools y use su herramienta de análisis para encontrar código redundante y deshacerse de él. Logré eliminar algo así como del cinco al diez por ciento del código en un producto antiguo de mi empresa.

Hiciste un gran trabajo formulando esta pregunta. ¡Gracias por preguntar! Y gracias a la comunidad por publicar respuestas inteligentes (como siempre).

Si se trata de una base de código bastante grande, y parece que lo es (50-100 VBPs interrelacionados, 200-500K LOC), entonces debería considerar invertir en herramientas de migración. Considere esta analogía: si tuviera una gran cantidad de datos para convertir, incluso si los datos de origen estaban sucios y eran muy diferentes del formato deseado, usaría herramientas. Si alguien le sugirió que simplemente debe volver a ingresar los datos, o incluso hacer una conversión aproximada y luego arreglarlos a mano, usted pensaría que estaban locos. También con 120 formularios, la aplicación parece que proporciona una cantidad bastante significativa de funcionalidad empresarial. Esa funcionalidad empresarial ha emergido durante muchos años de uso y, nos guste o no, el código VB6 representa una especificación completa, formal y probada en producción de esa funcionalidad, así como innumerables datos técnicos sobre cómo funciona la aplicación detrás de escena. Recopilar, recodificar y volver a probar todos esos requisitos funcionales / técnicos "desde cero" es muy costoso y difícil. Para administrar el costo y el riesgo del proyecto, debe "cobrar" el código heredado. La pregunta es: cómo hacer esto y también garantizar un menor costo de propiedad después de la migración.

El desafío tiene menos que ver con el tamaño de la base de código que con los detalles de rediseño necesarios para adaptarse y aprovechar .NET. Debe identificar las cosas específicas que hacen que el código VB6 sea "feo", por qué es "feo" y cómo debe / debería / desear hacer esas cosas de manera diferente en .NET. Una vez que comience a formular estos requisitos de rediseño, puede comenzar a implementarlos en su proceso de conversión para que aparezcan en su código .NET. El enfoque general que defendemos se llama " reescritura asistida por herramientas " y se realiza de la siguiente manera:

  1. correr la traducción
  2. construir / revisar / probar el código generado para identificar / refinar las mejoras necesarias del código
  3. Si el código generado es "suficientemente bueno", vaya a terminar el trabajo en .NET
  4. reconfigure el traductor para implementar las mejoras necesarias (si corresponde)
  5. goto 1

La salida de la herramienta no necesita ser "perfecta" (el software nunca es ...) solo necesita ser "lo suficientemente buena". Lo que es "suficientemente bueno" mencionado en el paso 3 es una pregunta crítica. En esencia, significa que la calidad del código, en términos de ser verificado como funcionalmente correcto y conforme a sus estándares, es tal que el equipo de desarrollo sabe lo que se necesitará para finalizar la migración y luego continuar operando / manteniendo la aplicación. Y son confiando en que pueden hacer esto dentro del tiempo dado y las limitaciones de recursos. Para una base de código muy grande, "lo suficientemente bueno" es "muy bueno" porque es demasiado costoso y arriesgado tratar de terminar y posteriormente mantener una migración de baja calidad. En general, cuanto mayor sea el código y menor sea el presupuesto, más eficiente será el proceso de migración.

También algunas reflexiones sobre "terminar el trabajo en .NET": tener un código bien formado en .NET es un hito importante. Existen buenas herramientas de refactorización, análisis y pruebas de unidad de la comunidad .NET que pueden ayudarlo a acelerar sus esfuerzos para finalizar la migración. Utilizará Visual Studio muy temprano en el proceso para experimentar y refinar el rediseño, y depurar / probar la aplicación. Ser capaz de trabajar con toda la base de código en .NET y con Visual Studio al principio del esfuerzo de migración es un beneficio clave (y una parte crítica) del enfoque asistido por herramientas.

Por supuesto, para que esto sea factible, debe poder invertir en un conjunto de herramientas de migración que está específicamente diseñado para respaldar la reescritura asistida por la herramienta. La herramienta de Great Migrations es la única herramienta que conozco en esta categoría.

Descargo de responsabilidad: trabajo para grandes migraciones. Hay mucha más información en nuestro sitio, incluidos estudios de casos sobre cómo se usó la herramienta para ayudar a migrar más de 1M LOC de VB6 a C # rediseñado, y el Manual del usuario de gmStudio que describe el producto y la metodología en detalle.

No lo reescribas desde cero. Parece que te llevará años y es muy probable que introduzcas errores nuevos (antiguos) en el código.

Miraría a refactorizar el código lenta pero simplemente. Empieza pequeño. Es sorprendente la rapidez con la que puede refactorizar el código a algo que es mucho más manejable. Y debería ser capaz de mantener el código ''funcionando'' al final de cada bloque de refractorización que haga.

ACTUALIZACIÓN: vale la pena señalar que la migración automatizada solo moverá sus problemas a un idioma diferente.

Tuve que pasar por lo mismo (aplicación Massive VB6 sin documentación y código horrible). La única ruta segura y razonable que puede tomar es la número 3. Para mejorar algo, primero debe entenderlo. Si tomas la ruta 1 o 2, te garantizamos que te quedarás con un desastre horrible.

Recuerde siempre tener en mente la idea de que su objetivo final es una migración completa a .NET. Cuando esté refactorizando, piense en cómo se verá el horrible soporte OO de VB6 en VB.NET o C #. Si es posible, cambie su código para facilitar la migración.

Es posible que desee considerar cambiar gran parte de su funcionalidad central a una DLL .NET y exponerla a VB6 a través de COM. Esto eliminará una cantidad ridícula de código de su VB6 y se espera que deje en su mayoría la lógica empresarial.

Lo más importante que debes recordar es que no seas un vaquero.

  1. Escribir pruebas para un módulo.
  2. Refactorizar un módulo.
  3. Prueba el módulo.
  4. Libera tu aplicación.
  5. GOTO 1