La compleja toma de decisiones sobre la migración desde Visual Basic 6.0 a .NET (III)
[Ref.: La compleja toma de decisiones sobre la migración desde Visual Basic 6.0 a .NET (II)]
Parece claro que en esta entrada dejo claro que personalmente prefiero rehacer el programa partiendo de cero que migrarlo, pero trataré de justificar teóricamente porqué en la mayoría de las ocasiones prefiero rehacer el Software en lugar de migrarlo:
– Los GoTo han pasado a mejor vida en .NET. Una migración de Visual Basic 6.0 a Visual Basic para .NET los podría respetar, pero es en sí una mala práctica que denota errores conceptuales de base sobre el desarrollo Software.
– El manejo de excepciones en .NET es completamente diferente al manejo de errores de Visual Basic 6.0. En muchas ocasiones, estaremos obligados a cambiar manualmente la forma en la que debemos o queremos gestionar los errores y excepciones en nuestra aplicación.
– El trabajo con multihebras en .NET ha cambiado mucho con respecto a Visual Basic 6.0. Incluso ha habido cambios entre las versiones iniciales de Visual Basic 2002 y Visual Basic 2003, y la posterior actualización de Visual Basic 2005.
– La aplicación de Visual Basic 6.0 podría tener multitud de controles ActiveX. Salvo que tengamos el código del control ActiveX, que no siempre es así, sobre todo al utilizar controles no estándar de Microsoft (controles ActiveX de otras compañías por ejemplo), la migración de los controles ActiveX sin código, es prácticamente imposible, y dada la naturaleza de desarrollo de los controles ActiveX, podemos tener más problemas que ventajas. Microsoft .NET Framework es un entorno de desarrollo de código manejado que utiliza unos tipos de datos diferentes a los que utiliza Visual Basic 6.0. A veces es necesario crear un envoltorio (wrapper) que permita utilizar los controles ActiveX sin problemas, pero eso no significa que estemos exentos al 100% de posibles fallos, errores o problemas. Otra diferencia de .NET con respecto a los ActiveX, es que la gestión de memoria de los objetos de una aplicación .NET la realiza Microsoft .NET Framework, por lo que el usuario debe preocuparse únicamente de codificar.
– Los eventos en Visual Basic 6.0 son parecidos en funcionamiento a los utilizados en Visual Basic para .NET pero diferentes en cuanto a declaración. Adicionalmente, hay otros aspectos nuevos a tener en cuenta en .NET como por ejemplo los delegados.
– Al trabajar con matrices, debemos tener en cuenta algunos cambios incorporados en .NET. Estos cambios pueden incluso provocar que nuestra aplicación migrada no funcione perfectamente.
– La conversión de tipos puede generar errores no esperados. El tipo de datos Variant ya no existe, y como contraprestación, el tipo de dato Object es el tipo de dato a partir del cual derivan el resto de tipos de datos de .NET.
– Si con Visual Basic 6.0 podíamos utilizar diferentes paradigmas para acceder y trabajar con datos (RDO, DAO, ADO), con .NET tenemos ADO.NET. El acceso a fuentes de datos a través de ADO.NET cambia radicalmente, y es necesario que el desarrollador conozca, al menos de forma teórica, cómo trabajar con fuentes de datos en .NET antes de adentrarse en el código migrado. De hecho, la migración requerirá casi seguro que tengamos que personalizar o modificar algunos cambios manualmente. Por otro lado, es muy posible que la arquitectura cambie de forma que tengamos que rehacer la capa de acceso a datos, y ya no digo nada si lo que queremos es trabajar con n-capas, WCF o LINQ.
– Un desarrollo de Visual Basic 6.0 no está orientado a objetos, carece de los mecanismos puros de la reutilización de código, no posee una nomenclatura idónea y hace que su mantenimiento sea complejo. Arrastrar esos defectos a una aplicación .NET al migrar ésta, es una mala práctica que deberemos evitar manualmente en la inmensa mayoría de los casos.
– La reutilización de código es en algunos escenarios, mucho más importante de lo que a priori puede significar. Con Visual Basic para .NET podemos desarrollar aplicaciones para diferentes entornos (Windows, Web, Mobile, etc).
– Las aplicaciones de Visual Basic 6.0 abusa por lo general, del uso de APIs. En .NET, debemos evitar al máximo el uso de las APIs. Recordemos que las APIs no se ejecutan en un entorno de ejecución de código manejado como lo hace .NET, y por lo tanto, mezclar código manejado con código manejado no es la mejor práctica. Además, debemos tener en cuenta que muchas de las APIs que usábamos en Visual Basic 6.0, tiene su correspondiente función o método manejado en .NET.
– La arquitectura utilizada en el desarrollo de Visual Basic 6.0 será arrastrada a .NET, y con ella los malos hábitos o incluso quizás una arquitectura obsoleta que es la utilizada en la aplicación original.
Como podemos ver, la toma de decisión sobre migrar una aplicación de Visual Basic 6.0 a .NET no es una tarea banal. Muchas empresas han dado pasos atrás cuando se han enfrentado a todas las cuestiones que propongo en esta entrada y a alguna más que se me escapa ahora.
No se trata de tener miedo, solo de analizar y tomar la decisión que consideremos adecuada sin mirar atrás.
En el mercado hay muchas empresas y personas dispuestas a ayudar a aquellos equipos de desarrollo que deseen realizar la migración de sus aplicaciones. Muchas veces no nos atrevemos a cruzar solos el puente que va al otro lado del río, pero acompañados sí nos encontramos más confiados. Lo que sí tenemos que tener claro, es que la migración tendrá una serie de costes asociados que deberemos asumir si queremos dar ese paso.
Pero los costes no solo son computables a la propia migración, debemos tener en cuenta también los “famosos” vicios de los programadores de Visual Basic 6.0.
Antes de migrar, conviene tener unos conocimientos base sobre .NET y en su caso, sobre Visual Basic para .NET. O incluso sobre C# si se decide dar el paso desde Visual Basic 6.0 a C#, pero en esta serie de entradas y de momento, solo tendré en cuenta la migración de Visual Basic 6.0 a Visual Basic para .NET.
Un desarrollador de Visual Basic 6.0 que desee pasar a .NET debe en mi modesta opinión, conocer los siguientes aspectos (no digo aprender, sino conocer):
– Teoría de la programación orientada a objetos.
– Arquitectura de Microsoft .NET Framework.
– Curso introductorio de Visual Basic 2005 para desarrolladores de Visual Basic 6.0 (dentro de poco disponible con los cambios de Visual Basic 2008).
– Conocer el entorno de desarrollo y de ejecución.
Desde el punto de vista de buenas prácticas, debería conocer estos otros aspectos:
– Nomenclatura de las aplicaciones en .NET para programadores de Visual Basic.
– Comentarios XML en el código.
– Organización del código en .NET (uso de Region).
– Guías de desarrollo y arquitectura (manejo de excepciones, pruebas y testing, refactoring, etc). Los P&P de Microsoft son una base de conocimiento ideal, una forma de hacer las cosas, no la forma en la que se deben hacer las cosas.
Debemos tener claro por lo tanto, que la migración de una aplicación de Visual Basic 6.0 a .NET requiere de un esfuerzo inicial con una serie de costes asociados. Al equipo de trabajo se le debe proporcionar los recursos que le permitan conocer el funcionamiento de un desarrollo en .NET para abordarlo con las máximas garantías posibles. También es indispensable utilizar una metodología de desarrollo adecuada. Como posible metodología de desarrollo del proyecto, aconsejo Scrum, si bien no es ni la única, ni tampoco tiene porqué ser la mejor.
4 Responsesso far
Jorge. Hay algo impiortante a la hora de migrar codigo; hay que reajustar el mismo en la plataforma original, es decir, en VB6 habría que hacer cambios importantes, muy importantes antes de migrar. Si tenemos una lista de N problemas potenciales a la hora de migrar, una buena idea sería tratar de solucionar al máximo parte de esos N elementos en VB6 (pe. desaparacer el uso de variants refactorizando en VB6, etc…) y una vez reducida a la mínima expresión dicha lista entonces realizar la migración.
Algo importante a destacar es que las clases son propensas a ser mejor migradas que los formularios por ejemplo, si hacemos un cambio arquitecónico previo en VB6 trasladando todo el codigo posible de formularios a clases podemos ganar también en la migración.
Salu2
Justamente para realizar lo que dice Julio, existe una herramienta muy buena llamada Code Advisor, la cual permite encontrar posibles errores en el código VB 6.0 antes de realizar la migración.
Otro punto a tener en cuenta en una migración de ésta índole es el hecho de alinear todos los aplicativos de una empresa a una sola plataforma.
Saludos
Cómo puedo migrar unas clases de vb06 a webserices de visal studio 2008, si cada clase manda a llamar a x numero de sp, como hago los llamados a esos sp’s deesde el web service y com voy comparando los datos de los mismos a su vez
Jorge. Me parece excelente tu pagina y este tema sobre la Migración. Ya que ayuda a tomar la decisión de si vale la pena o no Migrar o Rehacer de Cero. Estuve buscando mucho informacion y me di cuenta que el elevado costo y tiempo de migrar va ser mayor que rehacer de cero (segun mis calculos y con mis proyectos). Creo que la tuya es la mejor explicacion que he encontrado hasta el momento. Y me aclara muchas dudas. Te felicito y exitos. Espero que sigas con estas grandes labores para los programadores.