El dilema del programador

[Dokko]

Actualmente me encuento en un dilema que se que muchos de vosotros os habeis visto involucrados y realmente no se que hacer.

Tengo ante mi una aplicacion de gestion de empresa desarrollada durante varios años, en visual basic 6.0, completa y usandose pero con muchos fallos estructurales y de diseño, ademas esta escrita sin comentarios, de manera lineal (no hay funciones, clases, etc..) llena de Go To.
La cosa es, que hago:

a) Sigo con lo que hay dejandolo como esta y poniendo parches tal para cual.

b) rehacerla a vb .net y dejarla como esta

c) hacerla desde 0 a mi manera, pero basandome en la antigua.

d) huye, ahora que puedes!

que opinais? que se puede hacer?

[AgeR]

Yo optaría por la D, pero supongo que no será tan fácil XD

Bueno, pues depende de los parches y lo grande que sea la aplicación. ¿Cuánto tardarías en hacerla a tu modo? Si como dices está tan mal estructurada, yo tiraría a hacerla de nuevo, porque llegará un momento que será imposible de mantener estable.

[Tei]

Actualmente me encuento en un dilema que se que muchos de vosotros os habeis visto involucrados y realmente no se que hacer.

Tengo ante mi una aplicacion de gestion de empresa desarrollada durante varios años, en visual basic 6.0, completa y usandose pero con muchos fallos estructurales y de diseño, ademas esta escrita sin comentarios, de manera lineal (no hay funciones, clases, etc..) llena de Go To.
La cosa es, que hago:

a) Sigo con lo que hay dejandolo como esta y poniendo parches tal para cual.

b) rehacerla a vb .net y dejarla como esta

c) hacerla desde 0 a mi manera, pero basandome en la antigua.

d) huye, ahora que puedes!

que opinais? que se puede hacer?

La opcion mas inteligente es la D, huir. Porque el usuario nunca va a entender el tiempo M que tardaria en reescribir la aplicacion, y menos todabia el tiempo M + N  de seguir con ese codigo. Mucho menos las ojeras y la cara de haber sido violado por 75 homeless de la opcion A.

La opcion C es interesante. Sobretodo si puedes cobrar bien tu tiempo.

Considera la aplicación como un "prototipo" de lo que quiere el cliente. Ya tienes las pantallas, entiendes el concepto de la aplicacion, etc.. Tienes bastante trabajo avanzado.

A no parece ninguna opcion aceptable, a menos que los cambios sean triviales. Pero en un codigo tan ridiculamente mal escrito algo tan trivial como cambiar el texto de un label (para que ponga NºCliente: en lugar de NºCLI: ) puede convertirse en una pesadilla agonizante. Si el cambio no es trivial... pues terminarias con M+N en tiempo de desarrollo. Mas que hacerla de cero. Con un resultado de peor calidad que emplear M.

Lo unico que veo interesante, es que ese programa que tiene delante llevara mucho tiempo en produccion. Es codigo probado. Y eso no es despreciable. De todos modos como profesional sabes que les han construido la casa sobre arenas movedizas. Si les reescribes la aplicacion les estas haciendo un favor.

[josepzin]

¡¡¡¡Sin lugar a dudas D!!!!!  :lol:  :lol:  :lol:

Yo soy del tipo: lo hago de nuevo a mi manera, pero eso tiene un costo bastante alto de desarrollo que tienes que ver si te compensa...

[Dokko]

el problema principal, que por la manera que esta hecho, es inestable por x motivos,  se arregla una cosa y falla otra que teoricamente era 100% estable y asi siempre.

Si el coste de desarrollo es alto, pero es la aplicacion de  mi empresa y que vende la misma aplicacion a clientes.

Si pudiera hacer una aplicacion estable sin errores, facil de actualizar y estable, estoy haciendo una aplicacion eficaz y creo que compensaria más.

[[EX3]]

In-creible!, como programador habitual de Visual Basic 6.0 lo de programacion lineal sin procedimiento ni clases y el uso de instrucciones Goto me ha llegado al alma (al rico spaggetti, señora :lol:)

Coñas fuera. Yo en tu lugar y disponiendo de las opciones que planteas intentaria estudiar el programa y tratar de portarlo (je, rehacerlo desde 0 queria decir xD) en VB.NET. Yo estoy en una situacion identica a la tuya y no me permiten hacer esto. Le tienen autentica fobia a las nuevas tecnologias y prefieren seguir trabajando con un programa que falla si o si y que cuesta mas intentar mantenerlo que reescribirlo desde 0.

Salu2...

P.D.: Ojo, la opcion de corre y huye tampoco la descartaria

[Vicente]

D a ser posible. Rehacer una aplicación de 0 siempre tiene muchas movidas (sobre todo si tiene que ser compatible con lo que estás dejando atrás...).

Un saludo!

Vicente

[Dokko]

siempre que la BD sea igual,y se cojan esos datos, el resto no importa.

[chechocossa]

Tengo ante mi una aplicacion de gestion de empresa desarrollada durante varios años, en visual basic 6.0, completa y usandose pero con muchos fallos estructurales y de diseño, ademas esta escrita sin comentarios, de manera lineal (no hay funciones, clases, etc..) llena de Go To.

Si el coste de desarrollo es alto, pero es la aplicacion de mi empresa y que vende la misma aplicacion a clientes.

mmmm y la venden...  :evil:  :evil:

El otro día fui a la presentación de un software de gestión de "última generación y con tecnología de punta"... y estaba hecho todo con VB 5 y 6...

Creo que no es tan fácil como decir una opción u otra... la D es la más tentadora, pero si no se puede evitar, una buena solución tal vez sería desarrollar nuevos módulos paso a paso, que vayan renovando todo lo viejo, pero sin dejarlo de lado definitivamente, hasta que se termine la integración.
Una opción interesante es buscar por el lado de SOA y todo lo que ello propone.

[senior wapo]

No refactorices. Sigue con parches y haz un informe técnico recomendando rehacerla. No se rehará pero tendrás el recurso del "te lo dije".

Dado que la aplicación ha llegado a estar en ese estado, y que hablamos de una empresa española, deduzco que la visión de tu empresa es esta:

- Rehacerla además de retrasos introduce incertidumbre, lo cual es un riesgo, y puede costar dinero.
- Seguir como ahora es ir sobre seguro y solo nos cuesta estrés creciente en el currito que la mantiene. Eso no cuesta (directamente) dinero.

Aunque quién sabe, lo mismo te sorprenden.

Lo de que es española no es un desdén, es que nuestra (bajísima) productividad es intensiva en mano de obra y baja inversión, luego el escenario más probable es el que he puesto. O eso o que te hagan mantenerla y rehacerla en paralelo por el mismo sueldo y mas horas :p

[Kr0n]

La verdad es que te has dejado muchos factores sin indicar, como para poder hacer un análisis que se aleje un poco de lo especulativo. A saber:

-Tiempo del que dispones para este asunto
-Tiempo del que te dejan disponer
-Lo que piensan tus superiores o responsables, al respecto
etc.
-Situación de la empresa respecto al sw (en funcion de como se vende, mucho o poco interes hacia el programa, etc)

La cuestión principal es que si el software se vende como un producto, debería renovarse y mejorarse. Y que mejor oportunidad para escribirlo desde 0 bien hecho. Vaya, lo que viene siendo sacar una nueva release del programa, de la que podéis sacar buena rentabilidad si ya de paso añadís features nuevas y lo "modernizais".

También esta el tema de en que te toca esa aplicación: no es tuya y ahora te ha tocado mantenerla? Es sólo algo puntual? En función de esto (y de lo que te dejen hacer, ojo) deberías pensar si de cara a un futuro te va a interesar tener las cosas bien hechas o si por el contrario seguirás aplicando la estrategia de parchear y no mirar atras.

En fin, hay pocos datos para valorar, así que sentenciar algo como "re-escríbelo de nuevo, tu cerebro lo agradecerá a la larga" es complejo e inutil.

[Lex]

...

[Dokko]

-Tiempo del que dispones para este asunto
-Tiempo del que te dejan disponer
-Lo que piensan tus superiores o responsables, al respecto
etc.
-Situación de la empresa respecto al sw (en funcion de como se vende, mucho o poco interes hacia el programa, etc)

- 8h al dia
- 8h al dia excepto tareas de adminstrador, soporte al cliente, planificacion comercial, etc etc..
- van quemados despues de tantos años y parece una beta
- no vende muxo no

[josepzin]

Hace poco estuve en una situacion "parecida", digo parecida porque el unico que tenia algo de perder era yo y no dependia de ninguna empresa ni tenia que responder ante jefes ni nada. Y porque ademas es algo mucho mas pequeño que ese programa tuyo.

Hace varios años hice una web para una inmobiliaria, con busqueda de inmuebles y todas esas cosas. En esa epoca recien empezaba con los lenguajes de internet tipo PHP, ASP y las bases de datos MySQL y demás...
Cuando salió ese trabajo, los requisitos que me pidieron fueron ASP y ACCESS, por mi inexperiencia les hice caso y desarrollé la web con ASP + ACCESS... Nunca mais!!!

La web quedó bonita y funcional, pero internamente era inmodificable! (esto no fue culpa del lenguaje sino de mi inexperiencia). Ademas de problemas para encontrar servidores baratos con ASP+ACCESS y otros problemas de la mierda atomica de ACCESS...

Pero funcionaba y ahí quedó.

Hace poco la gente de la inmo me pidieron modificaciones y agregados y actualizaciones y etc....
Así que tuve este mismo dilema: apechugar con esa mierda de pagina que hice o rehacerla con PHP+MySQL... con el riesgo de trabajar MUCHO mas pero con la recompensa de tener una aplicacion estable y fácil de mantener y expandir.

Al final decidí correr el riesgo, perdí muchisimas horas en rehacer toda la web... muchas horas.
Pero valió la pena, la web quedó mucho pero muuucho mejor que si hubiera modificado el ASP, luego lo primero que hice fue cambiar de servidor a uno Linux jeje. Y me saqué de encima esa mierda de codigo y requisitos.

[Mr. Sandman]

Yo intentaria rehacerla de nuevo, es lo que yo hago cuando algo se me vuelve inestable.
Aunque puede que eso no te interese por la cantidad de trabajo que te puede llevar, en ese caso la "D" seria la que escogeria  :lol: