(28-02-2014 11:46)Jarry escribió:  yo creo que depende mas de que se este haciendo con ese codigo.
todos tenemos muertos en el ropero(algunos morgues enteras) pero si la idea es mejorar eso, y laburar bien para adelante no es tan terrible.
en cambio si el codigo es un desastre y se sigue laburando igual porque "total, anda" ahi si, como te dije en el otro thread.
corré, corré hasta que los veas asi \0/ de chiquititos.

this... si te dejan ir mejorandolo, es una buena oportunidad... para arreglar estos muertos nosotros soliamos dedicar un 25% del laburo a mejorar el codigo... ya estaba asi estimado... eramos varios en el equipo y el pm nos bancaba en eso... si no, rajaaaa... a los 27-28 te preocupa menos que las cosas sean lindas, siempre y cuando no te hinchen mucho los huevos y te paguen bien

$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$$

En mi caso lo rehago y a la mierda, copias funcionalidad y diseño.. es para mejor siempre.. hay basura que es imposible entender y mantener

http://www.joelonsoftware.com/articles/f...00069.html

Con el tiempo aprendes a tirarle estos cadaveres a los demas. Todo laburo tiene un muerto.

Si no te dejan tirar un rewrite bien piola: refactoriza lo que puedas.

Despues el resto va a depender de vos y de lo que te va a tocar en el dia a dia. Trata de venderle a tu jefe que el costo de hacer un cambio va a terminar siendo tan grande que no va a ser redituable seguir en el proyecto.

(07-03-2014 11:23)rulo escribió:  Si no te dejan tirar un rewrite bien piola: refactoriza lo que puedas.

Despues el resto va a depender de vos y de lo que te va a tocar en el dia a dia. Trata de venderle a tu jefe que el costo de hacer un cambio va a terminar siendo tan grande que no va a ser redituable seguir en el proyecto.

no tengo que venderle nada: me pidió un cambio bastante boludo y ya reventó en siete lugares distintos y sigue fallando. Algo que debería hacerse en una hora ya lleva dos días y voy por el tercero...


(que esté acá respondiendo y no codeando no tiene nada que ver o.O)

(07-03-2014 11:29)Vallo escribió:  

(07-03-2014 11:23)rulo escribió:  Si no te dejan tirar un rewrite bien piola: refactoriza lo que puedas.

Despues el resto va a depender de vos y de lo que te va a tocar en el dia a dia. Trata de venderle a tu jefe que el costo de hacer un cambio va a terminar siendo tan grande que no va a ser redituable seguir en el proyecto.

no tengo que venderle nada: me pidió un cambio bastante boludo y ya reventó en siete lugares distintos y sigue fallando. Algo que debería hacerse en una hora ya lleva dos días y voy por el tercero...


(que esté acá respondiendo y no codeando no tiene nada que ver o.O)

Lo mencione porque el que tiene que plantearle el cambio de "aca falta refactor viejah" al cliente es tu jefe. Y para eso vos se lo tendrias que plantear a el. Si el ya lo sabe deberia (en un mundo ideal) plantearselo al cliente. Al menos para que sepan que el tiempo de hacer cambios pelotudos aumenta exponencialmente. Va a llegar un momento en que el cliente no va a querer poner tarasca por 3 días de laburo, porque te pidio que cambies el estilo de un textbox.

Tal vez tu jefe lo sabe y le chupa un huevo.

justamente vengo de hablar con él y le dije que no va para más, pero él le quiere seguir metiendo cambios...

el lunes arranco el programa desde cero, ya fue.

Encaralo por el tema coste.

Si mantenerlo cuesta $$$$$ y rehacerlo $ , se rehace.
Si mantenerlo cuesta $ y rehacerlo $$$$$ , no.

No lo rehagas, probablemente falles.

No puedo encontrar el puto artículo que estaba buscando, pero había un chango que decía que cuando te chocás con un sistema legacy que es una verga, lo mejor que podés hacer es orientarlo a APIs. Arrancás haciendo una buena cobertura de tests sobre una parte del sistemita, y una vez que eso está testeado, lo splitteás en una API y un consumidor de esa API. Una vez que tenés la API definida, sos Gardel: hacé todo el refactor que quieras adentro de la API, que para afuera te chupa todo un huevo. Y gradualmente vas a poder ir creando consumidores de esa API que sean piolas, al punto de que el software legacy que dependa de este módulo siga consumiendo el endpoint pedorro que hiciste al splittear, pero los desarrollos nuevos usen el nuevo consumidor, que es feliz.

(07-03-2014 13:22)Desert69 escribió:  No lo rehagas, probablemente falles.

No puedo encontrar el puto artículo que estaba buscando, pero había un chango que decía que cuando te chocás con un sistema legacy que es una verga, lo mejor que podés hacer es orientarlo a APIs. Arrancás haciendo una buena cobertura de tests sobre una parte del sistemita, y una vez que eso está testeado, lo splitteás en una API y un consumidor de esa API. Una vez que tenés la API definida, sos Gardel: hacé todo el refactor que quieras adentro de la API, que para afuera te chupa todo un huevo. Y gradualmente vas a poder ir creando consumidores de esa API que sean piolas, al punto de que el software legacy que dependa de este módulo siga consumiendo el endpoint pedorro que hiciste al splittear, pero los desarrollos nuevos usen el nuevo consumidor, que es feliz.

ehm..

Es imposible testear porque la lógica está toda metida adentro de los windows forms. El sistema es de programación de unos equipitos que se conectan por usb, le tira comandos y responden los equipos, se configuran y se graban. No es super wow el sistema, pero desde el 07 que se sigue modificando el mismo código que ya de entrada tenía 0 diseño orientado a objetos, usando un lenguaje orientado a objetos. No hay casi clases, son todos formularios con la lógica mezclada y código repetido por doquier.

Mmm Vallo, me inclinaría por ver qué provecho le podés sacar vos a esa situación. Si en la empresa tenés los tiempos y ellos tienen la intención de llevar lo que tienen a algo mejor, y son concientes de que lo que tienen no está bueno, creo que podrías sacar mucho provecho, meter cosas nuevas, automatizar, y todo eso que nos hace más felices
Ahora, si tu rol en la empresa va a ser seguir emparchando algo feo, no creo que te valga mucho la pena. Ahí tendrás que evaluar qué otros pros/contras encontrás y decidir (Me reditúa? Me da lugar a aprender cosas nuevas a pesar del código? Me permite estudiar con tranquilidad y terminar mi carrera? ...)

Creo que estas cosas se solucionan hablando, podrías tener una charla para ver cuál es la visión de la gente en cuanto al código que tienen, y cuál es la idea que tienen para tu rol como programador... Y a partir de ahí, evaluá.

Código de mierda te vas a encontrar en todos lados, de hecho yo leo código mío de hace un tiempo y pienso "Cómo pude hacer esto de esta manera?", y ahí está la papa y la cosa positiva, en darse cuenta y mejorarlo.

Desconozco a los Windows Forms, pero... ¿No se puede sacar el código de ahí en un principio?

(07-03-2014 13:03).py escribió:  Encaralo por el tema coste.

Si mantenerlo cuesta $$$$$ y rehacerlo $ , se rehace.
Si mantenerlo cuesta $ y rehacerlo $$$$$ , no.

si lo tenes que plantear con el cliente this

al cliente le chupa un huevo cuan lindo/feo sea el codigo, le importa lo que puede hacer o no con el sistema.

(07-03-2014 14:28)Aye escribió:  Código de mierda te vas a encontrar en todos lados, de hecho yo leo código mío de hace un tiempo y pienso "Cómo pude hacer esto de esta manera?", y ahí está la papa y la cosa positiva, en darse cuenta y mejorarlo.

+1