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?
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.
Cita de: "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?
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.
¡¡¡¡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...
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.
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 ;)
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
siempre que la BD sea igual,y se cojan esos datos, el resto no importa.
Cita de: "Dokko"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.
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
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.
...
Cita de: "Kr0n"
-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
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.
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:
Rehacer mola, a todos nos gusta rehacer, pero estamos hablando de rehacer algo que lleva desarrollándose "varios años". No se va a rehacer en dos días ;)
Respecto a la BD dokko: si la aplicación y la BD nacieron más o menos a la vez y la aplicación es una castaña del quince, ¿no es una castaña del quince también la BD? Seguramente si la rehaces al final te va a tocar cambiar las tablas o tendrás que sufrir con un modelo mal diseñado...
Un saludo!
Vicente
Si es para la empresa para la que trabajas , es decir , lo haras en horario laboral... yo optaria por rehacerla desde 0 , serán ratos ya que tienes otras labores que realizar , pero mientras no se te echen encima exigiendote resultados para mañana , no veo el problema ( bueno si , las horas que le echaras pero y que :P )
pero porque D y no c# .NET o vb?
Cita de: "Dokko"pero porque D y no c# .NET o vb?
Yo con D me refería a tu opción d (la de pirarse :p). Esta claro que para rehacerla yo usaría un lenguaje .NET (VB.NET o C#, con lo que estés más cómodo).
Un saludo!
Vicente
JUAZ juaz ... yo cada vez que decias D pensaba que os referiais al D.. y yo ¿al D que no lo conoce ni dios..?
XDD
Jejejejeje
Cita de: "Vicente"Rehacer mola, a todos nos gusta rehacer, pero estamos hablando de rehacer algo que lleva desarrollándose "varios años". No se va a rehacer en dos días ;)
Respecto a la BD dokko: si la aplicación y la BD nacieron más o menos a la vez y la aplicación es una castaña del quince, ¿no es una castaña del quince también la BD? Seguramente si la rehaces al final te va a tocar cambiar las tablas o tendrás que sufrir con un modelo mal diseñado...
Un saludo!
Vicente
yo de BBDD entiendo mil veces mas que programar, y vamos, es para ponerse a llorar, hay valores repetidos por todos lados, porque segun me dijo los crystal reports no aguantan mas de 3 tablas y por eso se tuvo que repetir valores...
Eh, una cosa no quiero decir con esto que el programador que lo ha hecho sea malo, la aplicacion funciona decentemente, hay empresas que la usan, pero no tiene la calidad que deberia tener despues de estos años.
Es jugar con una cosa que explota por todos los lados es engorrosa de manejar y actualizar. Ha habido muchos fallos y errores, no solo el programador.
La D como primera opción.
Como segunda, parche (prioridad del hilo alta) + refactorización (prioridad del hilo baja).
Bueno, es obligatorio poner el siguiente enlace. Y como nadie lo ha hecho, me toca a mi:
Big Ball of Mud (http://www.laputan.org/mud/)
(http://www.laputan.org/images/pictures/spaghetti-medium.jpg)
Estoy con Vicente, tendemos a pensar que el trabajo de otro somos capaces de hacerlo en 2 patadas y más mejor y más super-mega-chuli :(
Me recuerda a la historia del netscape, cuando cambiaron el equipo de desarrollo y tuvieron la genial idea de rehacerlo :S alegando que estaba mal hecho.
Si el programa fuese tuyo deberías hacerlo desde 0 planteando primero el diseño en papel y si es para la empresa (y no puedes huir) aplicarle los parches necesarios guardandote una copia antes en el SVN/CVS de cada cambio gordo.
ains.
Como yo ya he estado en ese caso te comento:
- Aplicaciones llevadas desde la versión 1.0 (escrito en los comentarios) del Visual Basic.
- Locura: había una aplicación en la que como curiosidad cuatro personas (dos becarios y dos que nos estabamos rompiendo los cuernos) con el código fuente disponible, y número de líneas inferior a 1000 líneas (creo recordar) tenía que pasar dos veces por un mismo sitio para que la aplicación funcionase. No fuimos ninguno capaces de saber al razón de dichos dos pasos (era una mera repetición de código con asignaciones del tipo a=5.. etc..). Si lo dejabas en uno, no petaba pero no funcionaba bien. Fue la cosa más bizarra (en funcionamiento) que he visto en mi vida.
Afortunadamente ese código no me tocó a mi revisarlo.
- Mi caso: aplicación bastante gorda en vb 6, donde había más de 100 goto->gosub->return-> (gracias a Dios, crecí con el Spectrum 48Khz, y aunque solo lo usé para jugar, hizo que los GOSUB no me asustasen) los que la pasaron de vb4 a vb6 (pobres becarios) sudaron tinta y yo que tuve que "pulirla" también. Era una aplicación no convencional de oficina (mucho GDI). Cascaban el 75% de los REDIM. Hubo que cambiar todos los ciclos with -> for , bueno, otra pasada.
- ¿Modernizarla?: IMPOSIBLE: no hubiese podido usar casi nada del código y por supuesto, tenía que calcar al 100% el funcionamiento (no el 90%/91%/92%... el 100%).
Solución: cuando algo fallaba y parches por aquí, allá y más comentarios sobre lo que hacía el programa que código escrito.
Yo de este tema voy quemado, pq sigo en el punto de rehacerlo de 0 es una matada de tiempo, y siempre que me lo acepten y se cumplan ciertas condiciones.
Porque ponerte a mejorar el codigo y poner funciones, optimizarlo, corro el riesto de tocar una cosa y se caiga el resto. Es como un castillo de naipes de 3 plantas con 3000 cartas, donde necesitas esas cartas para hacer mas pisos...
Y porque dejarlo como esta, es como vaciar un cubo de agua con un colador, y ya empieza a doler el brazo y parece que esto no tiene fin.
Menos mal que el viernes me voy a la CP y algo hare..
Joder yo llevo ya año y pico con la opción A, pero al menos aquí no había GOTOs!!! Eso sí, los comentarios y la documentación brillan por su ausencia.
Supongo que la mas razonable pero tambien mas desagradable es la A.
Yo tambien llevo tiempo parcheando una aplicacion que es un truño y es realmente desagradable. A un compañero se le ocurrio "optimizar" una clase y de 7.000 lineas paso a tener despues de la optimizacion 13.000