¿Redisejarías completamente bajo .NET?

Question

Una aplicación muy extensa comenzó como un sistema basado en acceso (para el almacenamiento de la base de datos). Los formularios se escribieron en VB5 y/o VB6. A medida que .NET se convirtió en un accesorio en la comunidad de desarrollo, ciertos módulos han sido reescritos. Esto parece muy incómodo y potencialmente costoso solo de mantener debido a las tecnologías cruzadas y el trabajo adicional para mantener felices las dos tecnologías entre sí. Por supuesto, la aplicación utiliza una mezcla de ODBC OLEDB y MYSQL.

¿Pensaría que pasar el tiempo y los recursos para volver a desarrollar por completo la aplicación en .NET sería más rentable? En un esfuerzo por desarrollar una aplicación más estable, ¿no tendría sentido usar .NET? O continúe persiguiendo errores de acceso, agregando nuevas funciones en .NET (que pueden o no crear nuevos errores entre .NET y Access), y reescribiendo los módulos de acceso antiguos en módulos .NET bajo restricciones de tiempo que impiden un diseño y desarrollo adecuados.

ActualizarLa aplicación usa OLEDB y MySQL: corrigí mi declaración anterior.

Además, para prestar más apoyo a la reescritura: desde entonces he descubierto que cuando el "Porting" Comenzó a .NET, el código VBA/VB6 que existía se tradujo básicamente al equivalente .NET. Según tengo entendido, no se hizo nada para mejorar el rendimiento, o aprovechar nuevas bibliotecas o tecnologías.

En mi opinión, esto crea una aplicación muy frágil e inestable. Con cada nueva actualización, esto se vuelve cada vez más visible. Como técnico de la mesa de ayuda, he notado un aumento en los problemas reportados. Los clientes que usan el software han notado un aumento en los problemas y lo están comentando.

Answer 1

Muchas personas desalientan la reescritura de una aplicación desde cero y, a veces, estoy de acuerdo con el razonamiento. Pero la mayoría de las veces encuentro que reescribir la aplicación la solución menos dolorosa y cualquier cosa escrita en el acceso debe ser portada al período .NET. No me malinterpreten, el acceso tiene su lugar y puede proporcionar mucha funcionalidad a una organización, pero si se convierte en una aplicación completa en la que la gente confía, entonces tiene acceso mayor.

Probablemente no tomaría mucho tiempo transferir el VBA extistente a .NET en uno para una conversión. Pero esa puede no ser una gran solución si el VBA no es muy bueno para empezar. Un rediseño/reescritura tardará más en escribir, pero a la larga será mucho más fácil de mantener.

Casi siempre estoy en el campamento de reescribirlo desde cero en lo que respecta al acceso y no lo he arrepentido una vez.

Answer 2

Estoy de acuerdo con el enfoque de refactorización. Es muy probable que este sea un proceso lento que pueda tardar muchos meses en completarse, pero al mover una característica / sección a la vez tiene ventajas importantes que incluyen:

1. Se mantienen las características del producto.
2. Se mantiene la capacidad de entregar un nuevo lanzamiento.
3. Se elimina la presión de tiempo.

Buena suerte

Answer 3

En general, es una práctica desanimada para "reescribir" una aplicación desde cero (lo cual es un impulso normal que la mayoría de los programadores se sienten al menos varias veces en su vida) porque pasará de una aplicación con un conjunto de características conocido (¡y también errores conocidos!) a una aplicación con un conjunto menor de características y, lo que es más importante, errores desconocidos. Los usuarios podrían frustrarse, etc.

Probablemente estaría mejor si refactoró lentamente su aplicación durante un período de tiempo, evolucionando así su arquitectura durante un período de tiempo más largo.

Answer 4

Un gran desafío que experimenté con una reescritura de esa escala es tener que mantener dos bases de código al mismo tiempo. Si soluciona un error en el sistema heredado, debe asegurarse de que la funcionalidad funcione correctamente en el nuevo sistema y viceversa. La actualización de un módulo a la vez minimiza ese dolor de cabeza de mantenimiento.

También sería útil un suite de prueba de regresión completa que se ejecuta tanto en los sistemas heredados como de reemplazo.

Answer 5

Estoy de acuerdo con Jas, no reescribirá aplicaciones solo por reescritura. Es posible que nunca necesiten ser depurados o mejorados, entonces, ¿por qué perder el tiempo? Sin embargo, si cree que hay un cambio conmovedor en la experiencia de su nuevo desarrollador alquila el acceso a .NET, es posible que deba migrar antes de que sea demasiado tarde. Eso parece poco probable, pero una posible consideración.

Aunque puede que no sea rentable desde el punto de vista del desarrollo, ¿cómo se extiende las diferentes aplicaciones que afectan a los usuarios? ¿Requiere más capacitación de usuarios? ¿Están cometiendo más errores? ¿Aumenta el número de llamadas de soporte porque no pueden encontrar algo?

Answer 6

"¿Pensaría que pasar el tiempo y los recursos para volver a desarrollar por completo la aplicación en .NET sería más rentable?"

Esta no es una pregunta que se pueda responder aquí.

Desde la parte superior del requisito Pyramid: alguien tomó una decisión que con suerte puede justificar con un plan de negocios. En ese plan de negocios, debe indicar cuántas horas+costos adicionales se necesitan para convertir la aplicación y en ese mismo plan de negocios los beneficios se establecen también en términos de dinero.

Esa es la manera de hacerlo. Si no hay un plan de negocios para ello. Luego, la respuesta es trabajar primero en un plan de negocios rastreable para algunos casos de uso de alto nivel para realizar el análisis de impacto para verificar el inicio del proyecto.

Si el impulsor original del objetivo comercial que conduce al cambio ni siquiera se basa en el dinero, entonces esta persona es probablemente la que paga todo, por lo que debe hacerse.

Si no hay plan de negocios, pero "Simplemente está hecho", intente hacer uno y presentarlo a la alta gerencia. Incluya casos de alto nivel de usos, costos, horas de rediseño, construcción, costo adicional para operaciones, nueva capacitación para administradores y enduscadores, gestión de proyectos y riesgos potenciales.

En mi humilde opinión, esta no es una pregunta técnica.