«El código de vuestra base de datos», @blip, pregunta antes de escribir ;-).
¿Quién no se ha encontrado con esto?. Seguramente es del típico programador que no hacer más que liarla y que deja el proyecto justo antes de la entrega para que el marrón se lo coman otros.
@Gutierrez … puede referirse a paq uetes, procedimientos o funciones, peor si es algo raro.
Ahora quien no se ha encontrado con que… «oye como te fuiste de vacaciones y había que arreglar el color naranja, le dije a mi sobrino que sabe que blablabla»
Debe ser uno de esos códigos autoengendrados. ¡Como los ISOs de Tron Legacy! El futuro de la raza. Y Abelman está a punto de descubrir sus secretos. ¡Que privilegio!
Voy a romper una lanza en favor del programador. En mi experiencia, en muchos casos las chapuzas se deben a mala gestión y no tanto a mala programación. Tal vez el código original, sin varias generaciones de parches y modificaciones, funcionaba de maravilla para su propósito original. Luego viene cuando el propósito se va desplazando poco a poco de una cosa concreta, pequeña y bella a un coloso con un propósito totalmente diferente a base de becarios, inútiles, chapuzas y prisas. No será la primera vez qué pregunto «qué mierda hacen todas estas líneas de código muerto» (clases que no se referencias, condicionales que nunca se cumplen, etc) y el veterano me dice: «es que hace 15 años, cuando esto se programó, se supone que tenía que hacer tal y cual y entonces sí se referenciaba; supongo que los que hicieron los cambios se lo han dejado ahí». Y como todos sabemos, el refactoring es para los pobres y los tontos…
Otro de los comunes es: «me vas a preparar un prototipo para enseñar en dos meses, y si lo vendemos nos ponemos ya en serio y hacemos algo en condiciones». El pobre ingeniero se apaña un código cuyo propósito es impresionar a un cliente (esto es, una interfaz lustrosa que apenas funciona pero tiene todo lo que los de marqueting y diseño han ido pidiendo sobre la marcha) y cuando el señor jefe viene de la reunión suelta: «¡Enhorabuena! ¡Lo hemos vendido!», todos aplauden y luego ya en privado el jefe se acerca y le dice: «Dilbert, tienes otro mes más para meter lo que falta y esto sale para producción». El ingeniero dice: «pero poner todo esto en marcha me va a llevar entre 6 y 9 meses, dame 18 si quieres algo que sea más que simplemente decente». El jefe le dice al ingeniero: «¡Pero si ya lo tienes todo prácticamente funcionando! Mira, vas a coger lo que ya tienes hecho y terminas la funcionalidad que no está puesta. Si necesitas más tiempo puedo darte otro mes más.»
Y así, amigos míos, es como se acaba con un software de mierda, con código muerto y/o duplicado, sincronización a base de sleeps, interfaces que no se respetan, absolutamente inmantenible y, la joya de la corona, SIN DOCUMENTAR. Because fuck you, that’s why…
¿Conocéis «The Story of Mel»? Es una historia muy mítica sobre un código de este tipo. Los programadores la vais a disfrutar; los demás, no entenderéis nada. http://en.wikipedia.org/wiki/The_Story_of_Mel
Pero mira como embebe el código en Python,
pero mira como embebe el HTML…
En cuanto se encienda la Impresora.. en cuanto se encienda la impresora
Esto me recuerda a las tarjetas Black de Bankia XDD, nadie sabe el autor pero todos echan la culpa al anterior, Alabada sean los corruptos!!
Por supuesto, el autor del código original no lo firmó. Yo tampoco lo hago en esos casos de CódigoChapuza(TM).
«El código de vuestra base de datos», @blip, pregunta antes de escribir ;-).
¿Quién no se ha encontrado con esto?. Seguramente es del típico programador que no hacer más que liarla y que deja el proyecto justo antes de la entrega para que el marrón se lo coman otros.
@Gutierrez … puede referirse a paq uetes, procedimientos o funciones, peor si es algo raro.
Ahora quien no se ha encontrado con que… «oye como te fuiste de vacaciones y había que arreglar el color naranja, le dije a mi sobrino que sabe que blablabla»
@kdelamo, créeme, no se está refiriendo a eso porque ni sabe lo que es ;-). Normalmente pregunta antes pero esta vez no lo hizo.
@Gutiérrez: que sí, que sí, que me refiero a un paquete de esos que dice @kdelamo! desconfiada!
@Gutierrez, ¿tú también te dejas notas en el code en plan «futuro yo o quien sea, esto funciona no sé muy bien cómo, no tocar»?
@LiMaX: Yo siempre sé porqué funciona. Suena prepotente pero es cierto. 😉
Esa es mi chica <3
Debe ser uno de esos códigos autoengendrados. ¡Como los ISOs de Tron Legacy! El futuro de la raza. Y Abelman está a punto de descubrir sus secretos. ¡Que privilegio!
@Gutiérrez No dudo de tí 🙂
Comentarios del tipo «NO TOCAR O TE CORTO LOS HUEVOS/OVARIOS»? xDDD
Dónde c%$»#s estaba el post de ender sobre el tema?
Voy a romper una lanza en favor del programador. En mi experiencia, en muchos casos las chapuzas se deben a mala gestión y no tanto a mala programación. Tal vez el código original, sin varias generaciones de parches y modificaciones, funcionaba de maravilla para su propósito original. Luego viene cuando el propósito se va desplazando poco a poco de una cosa concreta, pequeña y bella a un coloso con un propósito totalmente diferente a base de becarios, inútiles, chapuzas y prisas. No será la primera vez qué pregunto «qué mierda hacen todas estas líneas de código muerto» (clases que no se referencias, condicionales que nunca se cumplen, etc) y el veterano me dice: «es que hace 15 años, cuando esto se programó, se supone que tenía que hacer tal y cual y entonces sí se referenciaba; supongo que los que hicieron los cambios se lo han dejado ahí». Y como todos sabemos, el refactoring es para los pobres y los tontos…
Otro de los comunes es: «me vas a preparar un prototipo para enseñar en dos meses, y si lo vendemos nos ponemos ya en serio y hacemos algo en condiciones». El pobre ingeniero se apaña un código cuyo propósito es impresionar a un cliente (esto es, una interfaz lustrosa que apenas funciona pero tiene todo lo que los de marqueting y diseño han ido pidiendo sobre la marcha) y cuando el señor jefe viene de la reunión suelta: «¡Enhorabuena! ¡Lo hemos vendido!», todos aplauden y luego ya en privado el jefe se acerca y le dice: «Dilbert, tienes otro mes más para meter lo que falta y esto sale para producción». El ingeniero dice: «pero poner todo esto en marcha me va a llevar entre 6 y 9 meses, dame 18 si quieres algo que sea más que simplemente decente». El jefe le dice al ingeniero: «¡Pero si ya lo tienes todo prácticamente funcionando! Mira, vas a coger lo que ya tienes hecho y terminas la funcionalidad que no está puesta. Si necesitas más tiempo puedo darte otro mes más.»
Y así, amigos míos, es como se acaba con un software de mierda, con código muerto y/o duplicado, sincronización a base de sleeps, interfaces que no se respetan, absolutamente inmantenible y, la joya de la corona, SIN DOCUMENTAR. Because fuck you, that’s why…
@Gutierrez es de las mias pues, tengo mas anotaciones en el codigo, que parece dummies, x ej:
// Cuando se quiera cargar la barra pasar valor true a ShowBar
No me imagino cómo una paloma pudo picar código, con esas alas empumadas imposible… y con esas patitas tampoco lo veo. Misterios de la fé.
Utilizando un aragonesismo: ¡qué «tiquismiquis» sois, @Gutiérrez y @Abelman! Se entiende perfectamente lo que quiere decir.
@blip: te cojo prestada la idea de código/aplicaciones/programación generadas por «Inmaculada Concepción». Brillante.
P.S.: Sí, sí, yo también soy purista con el lenguaje como el que más.
¿Conocéis «The Story of Mel»? Es una historia muy mítica sobre un código de este tipo. Los programadores la vais a disfrutar; los demás, no entenderéis nada. http://en.wikipedia.org/wiki/The_Story_of_Mel