¿Volvería a diseñar completamente bajo .Net?

8

Una aplicación muy extensa comenzó como un sistema basado en Access (para el almacenamiento de bases de datos). Los formularios fueron escritos en VB5 y / o VB6. A medida que .Net se convirtió en un elemento fijo en la comunidad de desarrollo, ciertos módulos se han reescrito. Esto parece muy incómodo y potencialmente costoso solo por mantener debido a las tecnologías cruzadas y el trabajo adicional para mantener las dos tecnologías felices entre sí. Por supuesto, la aplicación usa una mezcla de ODBC OleDb y MySql.

¿Creería que pasar el tiempo y los recursos para volver a desarrollar completamente 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 continuar persiguiendo errores de Access, agregando nuevas características en .Net (que pueden o no crear nuevos errores entre .Net y Access), y reescribiendo módulos de Access antiguos en módulos .Net con limitaciones de tiempo que impiden un diseño y desarrollo adecuados?

Actualización La aplicación usa OleDb y MySql. Corrigí mi declaración anterior.

Además, para prestar más apoyo a la reescritura: desde entonces descubrí que cuando comenzó la "transferencia" 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 las 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 más y 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 están comentando al respecto.

IAbstracto
fuente
44
Tendría que demostrarle a su jefe (o quien sea que decida) que vale la pena. Si es lo suficientemente malo, probablemente obtendrá la ventaja. No subestimes la tarea de reescritura: pasarás mucho más tiempo del que esperas para que sea de calidad de producción.
1
¿Por qué la aplicación usa ODBC y MySql?
kirk.burleson el

Respuestas:

16

Mucha gente desalienta 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 es la solución menos dolorosa y todo lo escrito en Access debe ser portado a .NET - PERIOD. No me malinterpreten, Access tiene su lugar y puede proporcionar una gran cantidad de funcionalidades a una organización, pero si se convierte en una aplicación completa en la que la gente confía, entonces ha superado a Access.

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

Casi siempre estoy en el campo de reescribirlo desde cero en lo que respecta a Access y no me he arrepentido ni una vez.

Walter
fuente
Todos aquí tienen buenas respuestas y me han dado una pausa para considerar su punto de vista. Tu punto de vista, @Walter, es donde estoy. No considero que el VB esté mal escrito de ninguna manera. Pero es VB. La tienda ha estado escribiendo VB desde el principio. Soy el chico nuevo con experiencia en VB.Net y C #. Me dieron margen de maniobra para escribir en C #. Entonces, por supuesto, tengo ideas y quiero implementarlas.
Resumen de
77
+ 1M para "cualquier cosa escrita en Access debe ser portada a .NET - PERIOD". El acceso es un juguete.
Steven A. Lowe
1
Puedo dar fe de la respuesta de Walters. Personalmente, he trabajado en un proyecto para volver a escribir un servicio web con errores de C ++ en C # (.Net 2.0) y una aplicación web ASP.Net 1.1 en ASP.Net 2.0 con AJAX para un importante banco australiano. El proyecto fue un verdadero éxito y éramos un pequeño equipo enfocado de 5. Dos cosas que debo señalar. 1. Nos comprometimos a admitir problemas de producción en la versión anterior hasta que la nueva versión esté lista, pero no agreguemos ninguna característica nueva. 2. A menos que sea realmente crítico, no se agregaron nuevas funciones al código reescrito, solo una función funcional por copia de función con errores corregidos, mejora del rendimiento, etc.
softveda
1
Si todos los demás conocen VB, elegir C # en lugar de VB.net es una mala elección. El hecho de que tenga {} no significa que sea lo mejor para cada solución. VB encajaría mucho mejor en este caso.
gbjbaanb
Y esta es la razón por la que no debería saltar al "permite reescribir": Pratik (o sus sucesores) ahora están apoyando un antiguo proyecto ASP.NET 2.0 / Ajax / .NET framework 2.0 deseando poder reescribirlo en algo moderno, tal vez C + +11 :-)
gbjbaanb
5

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

  1. Se mantienen las características del producto.
  2. Se mantiene la capacidad de entregar una nueva versión.
  3. Se elimina la presión del tiempo.

Buena suerte

Michael Shaw
fuente
La refactorización ha estado ocurriendo durante al menos un año y está programada para continuar durante el próximo año o dos. Parece que los recursos podrían ser: (1) mejor utilizados para mantener el estado actual de la aplicación y corregir errores, y (2) diseñar la aplicación para que sea completamente .Net y migrar las características .Net actuales al nuevo diseño. Parece que, con un buen núcleo .Net, la aplicación podría ser más flexible, estable y más tolerante para agregar nuevas características.
Resumen de
Al leer la pregunta, parece que la aplicación se ha portado, por ejemplo, en lugar de refactorizar, lo que implicaría reorganizar, cambiar y probar.
Michael Shaw
2

En general, es una práctica desaconsejada "reescribir" una aplicación desde cero (que es un impulso normal que la mayoría de los programadores sintieron al menos algunas veces en su vida) porque pasará de una aplicación con un conjunto de características conocidas (¡y errores conocidos también!) a una aplicación con probablemente un conjunto de características menores y, lo que es más importante, errores desconocidos. Los usuarios pueden frustrarse, etc.

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

Jas
fuente
Los usuarios ya están frustrados. La depuración de .Net es mucho más amigable y rápida que tratar de depurar Access. Además, un marco extenso basado en una tecnología que, francamente, no estaba destinada a un uso y una funcionalidad tan extensos es un desastre a la espera de suceder, especialmente, en mi opinión, cuando comienzas a intentar integrar una nueva tecnología. La integración de .Net en Access a menudo podría significar que no está utilizando .Net en todo su potencial debido a las limitaciones de acceso.
Resumen de
1

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 corrige 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 conjunto completo de pruebas de regresión que se ejecute tanto en los sistemas heredados como en los de reemplazo.

Larry Coleman
fuente
Este es exactamente el desafío ... todo lo que se arregla en la base de Access debe probarse para verificar su compatibilidad con la base .Net, y viceversa.
Resumen de
La otra desventaja de la reescritura desde cero es que los usuarios no obtienen nada hasta que haya terminado. Al menos al reemplazar un módulo a la vez, tienen la oportunidad de ver algunas mejoras pronto.
Larry Coleman
0

Estoy de acuerdo con Jas, no reescribas las aplicaciones solo por reescribirlas. Es posible que nunca necesiten ser depurados o mejorados, entonces ¿por qué perder el tiempo? Sin embargo, si siente que hay un cambio dinámico en la experiencia de sus nuevos empleados contratados fuera de Access to .NET, es posible que tenga que migrar antes de que sea demasiado tarde. Eso parece poco probable, pero una posible consideración.

Si bien puede no ser rentable desde el punto de vista del desarrollo, ¿cómo afecta la difusión de diferentes aplicaciones a los usuarios? ¿Requiere más capacitación del usuario? ¿Están cometiendo más errores? ¿Aumenta el número de llamadas de soporte porque no pueden encontrar algo?

JeffO
fuente
El mayor cambio en la refactorización de módulos individuales es la forma en que los formularios se ven en la parte frontal y se mueven a MySql en la parte posterior. Hay algunos cambios funcionales menores a los que los usuarios deben acostumbrarse. Pero en su mayor parte, hay una nueva capacitación independientemente de la cantidad de modificaciones, nuevas características, etc. Comúnmente tenemos bloqueos en Access (formularios, datos, etc.) que obligan a reiniciar el programa a pesar de que la parte .Net todavía tiene cierto nivel de capacidad de respuesta.
Resumen de
0

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

Esta no es una pregunta que pueda responderse aquí.

Desde la cima de la pirámide de requisitos: 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 expresan también en términos de dinero.

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

Si el impulsor original de la meta comercial que condujo 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 un plan de negocios pero "ya está hecho", intente hacer uno y preséntelo a la alta dirección. Incluya casos de uso de alto nivel, costos, horas de rediseño, construcción, costo adicional para operaciones, capacitación nueva para administradores y usuarios finales, gestión de proyectos y riesgos potenciales.

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

Edelwater
fuente