Solución de software de los años 2000, ¿debería intentar parchear o rehacer todo?

9

Me enviaron a discutir un sistema que cierta compañía está usando actualmente y qué se debe hacer con él.

La compañía fabrica varias pantallas de cartón. Este sistema fue desarrollado para realizar un seguimiento de los clientes, pedidos y precios. Han sucedido muchas cosas desde que se creó el sistema y el sistema ahora está, como lo describió el gerente, " bloqueado " y " problemático ", lo que traduzco como "no dinámico" e "inestable".

Alguna información sobre el sistema

  • Fue desarrollado alrededor del año 2000
  • Sistema bastante pequeño, 2-5 usuarios, 6 formularios, ~ 8 tablas con cantidades promedio de datos
  • Construido en Visual Basic temprano, formularios creados con el diseño de arrastrar y soltar La interfaz es básicamente una ventana con un menú y algunas formas.
  • Utiliza la base de datos MSSQL (servidor SQL2005) para almacenar datos y el controlador ODBC para consultar, los datos se migraron de Excel antes de este sistema, y ​​antes de Excel se manejó, calculó y escribió a mano y en papel.
  • Los usuarios trabajan en el entorno de Microsoft XP (y hasta)

Su principal problema es que ya no pueden ajustar y calcular precios, no pueden agregar nuevos tipos de cajas de cartón, etc., porque no pueden (o más bien, no saben cómo) tocar los datos en el servidor.

Sugerí 3 posibles soluciones

  1. Intentar parchear el sistema actual
  2. Cree una nueva interfaz nueva (preferiblemente entorno similar, basado en VB.net o VB)
  3. Devuélvalo a una solución de Excel, considerando que es un sistema tan pequeño

Puede haber más opciones, pero estas son las que se me ocurren.

Mis preguntas son

  • ¿Qué debería recomendar y por qué?
  • ¿Cuáles son o podrían ser los pros y los contras de estas alternativas?
  • ¿Hay otras alternativas (posiblemente mejores)?
sql refactoring excel visual-basic ShadowScripter
fuente
3
No puede decidir qué tan dañado está el sistema actual hasta que haya documentado los esquemas de la base de datos.
@ ThorbjørnRavnAndersen Eso es cierto. Solo he echado un vistazo a la base de datos. A juzgar por la edad en que se creó, voy a suponer que está realmente terriblemente diseñado y necesita primeros auxilios ... o cirugía.
ShadowScripter
1
¿Sabes quién escribió el sistema original? ¿Fue un esfuerzo interno o fue subcontratado?
maple_shaft
77
No hagas eso. Dígale al cliente que el estado de la base de datos es crucial para el costo de las diversas opciones, y debe hacerse independientemente de la opción que elija. Incluso para una reescritura desde cero, lo más probable es que quieran transferir sus datos.
44
Los desarrolladores prefieren "reescribir desde cero" y refactorizar solo cuando es necesario. Prefiero usar "refactorizar gradualmente" y solo reescribir cuando sea necesario.
quant_dev

Respuestas:

5

Algo con solo 6 formularios y tal debería ser fácil de reconstruir en un marco más moderno. He trabajado con la migración de proyectos VB6 que tenían alrededor de 200 formularios junto con docenas de clases y tablas de bases de datos. No parece que estés mirando algo tan desordenado, pero la apariencia puede ser engañosa.

Tendría que analizar el código, la base de datos y los requisitos comerciales para decir si sería mejor reescribir o refactorizar la base de código existente. Dado lo que has dicho, me inclinaría hacia una reescritura. Pero, podría haber dificultades ocultas que no ves en este momento.

jfrankcarr
fuente
Dado su pequeño tamaño, estoy de acuerdo. De un vistazo, tampoco parece demasiado complejo. A juzgar por las respuestas, una reescritura parece más apropiada. Sin embargo, echaré un vistazo más de cerca antes de tomar una decisión final. ¡Gracias por el consejo! :)
ShadowScripter
@ShadowScripter Echaré un vistazo a escribirlo en un lenguaje mejor que VB mientras lo haces. Echa un vistazo al proyecto de código abierto Lazarus .
Spencer Rathbun
5

Tengo un consejo ligeramente diferente la mayoría de las respuestas hasta ahora.

Intentar parchear el sistema actual

Al menos, aprendería el sistema actual lo suficientemente bien como para explicarle al cliente cómo usarlo. Me tomaría este tiempo para explicar las fallas en su sistema actual, evitar palabras negativas, simplemente decirles lo que no puede hacer, incluso si se corrigieron todos los errores conocidos.

Cree una nueva interfaz nueva (preferiblemente entorno similar, basado en VB.net o VB)

Después de haber aprendido todo lo que pueda con su configuración actual. Bríndeles opciones, si puede abordar sus preocupaciones con su sistema actual, realmente no hay nada de malo en su sistema actual. La única preocupación, por supuesto, es que el soporte de Visual Basic 6 podría no existir en 5 años.

Otra preocupación es la forma en que se comunica con la base de datos. Microsoft se está deshaciendo lentamente de algunas de las formas más antiguas de comunicarse con sus productos de base de datos (Access, MSSQL), por lo que la forma en que interactúa con esos productos determinará si la solución se puede usar en Windows 9 y Windows 10 en el futuro.

Esta respuesta depende completamente del hecho de que tienen la fuente de la aplicación en sí. Si no tienen la fuente, será difícil abordar sus inquietudes, corregir los principales errores actuales o incluso convertirla en una herramienta que realmente puedan usar.

No creo que haya nada "incorrecto" con una aplicación de Visual Basic 6, además del hecho, su soporte para futuras versiones es desconocido. Incluso hoy en día con los sistemas operativos Windows 7 y 64 bits, es cada vez más difícil de soportar. Esta es una de las principales razones por las que reescribir en un lenguaje moderno con el soporte adecuado de 64 bits podría ser una buena idea.

Si no tienen la fuente en ese momento, una reescritura es realmente su única solución.

Ramhound
fuente
¿Podría citar una referencia a " Microsoft is slowly getting rid of some of the older ways to communicate..."? Me gustaría leer más al respecto.
ShadowScripter
@ShadowScripter: por ejemplo, el proveedor Microsoft.Jet.OLEDB.4.0 para acceder a los archivos heredados de la base de datos de Access no es compatible cuando el proceso no es un proceso de 32 bits. WinRT también podría cambiar la forma en que nos conectamos con estos productos de Microsoft. Olvidé dónde leí sobre un cambio futuro, entiendo que después de MSSQL 2012, Microsoft solo admitirá una forma específica de conectarse también. Esto, por supuesto, en el contexto de los proveedores integrados en Windows y sus ofertas de desarrollo
Ramhound el
1

Reescribir la interfaz es una excelente opción, dado que el sistema es relativamente pequeño. Las ventajas son:

  1. Estabilidad mejorada (¡suponiendo que lo haga bien!)
  2. Mantenimiento mejorado
  3. Interfaz moderna

La principal desventaja es que probablemente costará un poco más que piratear el código existente.

Craig Schwarze
fuente
Reescribir la interfaz es a lo que me estaba inclinando también. Y para ser honesto, no estoy seguro de dónde comenzaría con la interfaz anterior, a juzgar por los estándares actuales, es tan ... malo en general.
ShadowScripter
1

También tendería a reescribir, pero debes estar 100% seguro de que entiendes completamente la funcionalidad actual, así como cualquier funcionalidad que esté rota, faltante o inadecuada. Los dos últimos son importantes, ya que mencionó ajustar y calcular los precios. ¿Entiendes completamente las consecuencias de agregar esta función?

Una vez trabajé en lo que se suponía que era un "sitio web", pero en realidad me hice cargo de una herramienta de estilo CRM basada en Access personalizada de finales de la década de 1990 y la introduje en el mundo moderno basado en la web. El desarrollador original se había ido hace mucho tiempo, la base de datos había sido modificada innumerables veces, la documentación original estaba desactualizada y nadie entendía realmente cómo funcionaba el sistema. Pero ellos sabían cómo usarlo, solo. Probablemente el 80% del presupuesto para este proyecto se destinó a tres cosas:

  • reunir requisitos
  • entender el sistema actual
  • proponiendo un esquema de base de datos significativo sobre cómo pretendían usar el software

¡El proyecto, financieramente, no fue un éxito!

ZweiBlumen
fuente
Escucho lo que estás diciendo: antes de tomar una decisión final, necesito ser plenamente consciente de sus fallas, funciones y propósitos actuales. ¡No es que quiera entrar todo, con las armas encendidas, gritando All right, let's do this. LEEEEEEEROOOOOOOY...! : P
ShadowScripter
0

Otra opción podría ser un compromiso entre reescribir todo y piratear la aplicación existente.

Bríndeles la nueva funcionalidad en una nueva aplicación creada desde cero.

Potencialmente, esto podría ser más fácil de hacer y no costará tanto como una reescritura completa.

Una vez que esto se haya hecho y estén contentos de poder agregar / actualizar datos, se abre la puerta de entrada, una fase dos podría estar reemplazando la funcionalidad existente en la nueva aplicación.

Este podría ser un enfoque más apetecible.

ozz
fuente
1
Supongo que es una buena idea, pero si la fase dos nunca sucede, terminarán con una aplicación separada anterior que depende de la otra aplicación nueva, dejándolas con dos aplicaciones y el doble de problemas.
ShadowScripter
0

Las reescrituras a menudo tienden a quedarse sin presupuesto ... Mal.

Pero tener un esqueleto moderno para la aplicación puede ser una buena inversión, especialmente si nadie sabe cómo funciona el sistema antiguo y si las cosas se rompen tan pronto como empiezas a tocarlas.

Además, VB6 es malo para el soporte. Cuando necesite encontrar especialistas en 10 años, será bastante problemático.

Descifrador
fuente