Acabo de heredar 200,000 líneas de código espagueti. ¿Y ahora qué?
Abraham
Esta es la pregunta que ha planteado Kevin Mote en stackexchange.com. Kevin acaba de conseguir un nuevo trabajo en una pequeña empresa como un ingeniero de software y acaba de heredar una base de código que ha sido desarrollada durante dos décadas por un conjunto de personas con bastante conocimiento sobre el dominio de aplicación, pero con pocos conocimientos sobre ingeniería de software. Como es de esperar dados esos antecedentes, desde un punto de vista de arquitectura y mantenebilidad el código es un desastre.
Kevin ha pedido consejos a la comunidad, y su post tiene muy buenas respuestas, especialmente la de Laurent Malvert (la primera, la que tiene un mayor número de votos). La respuesta es muy extensa (cerca de 30,000 caracteres) pero os dejo aquí lo que Laurent Malvert llama "resumen de ejecutivo" de su respuesta:
- Definir una estructura rígida de proyecto conplantillas de proyecto, convenios de código, sistemas de build y guías de uso para toda la infraestructura y las herramientas.
- Instalar un sistema de control de versiones y enseñar a todo el mundo a usarlo.
- Elegir un buen entorno desarrollo y enseñar a todo el mundo a usarlo.
- Emplear sistemas de chequeo de calidad de código y sistemas que generen métricas sobre el código automáticos.
- Emplear sistemas de integración continua.
- Identificar los puntos más desastrosos de la base de código y comenzar a refactorizar por ahí.
Podéis leer la respuesta completa aquí.
¿Os habéis visto vosotros en alguna situación similar? En caso afirmativo, ¿Qué es lo que hicisteis?
Reader Comments (22)
Estoy convencido de que todos hemos pasado por esto. Incluso me atrevo a decir que muchos firmaríamos para que solo fueran 200K lineas.
Decir que los analistas/programadores anteriores no sabían mucho de ingeniería del software es bastante arriesgado. Estamos hablando de un código de dos décadas, fijo que sometido a muchísimos cambios por cambio salvajes de requerimientos. El problema es el tiempo, es decir coste. Muchas veces sabes perfectamente como hacer las cosas bien, pero cuando le explicas a tu gerente que es para evitar hacer una mierda o minimizar posibles gastos futuros, lo mas normal es que te mande a la mierda. Si el código no esta pensado desde inicio con metodologías que hace 2 décadas no existían, apostaría a que les sera imposible aplicarlas ahora ya que la mayoría de gerentes solo desean resultados absolutamente inmediatos, y si luego queda una basura para el siguiente gestor pues que se joda, que el ya se ha puesto las medallas.
La teoría esta muy bien, pero me gustaría saber cuantos de vosotros, sabiendo como hay que hacer las cosas, podéis aplicarlo sin ir a la puta calle.
Son buenas propuestas y típicas. Si hay un equipo de desarrollo que no tiene buenas prácticas de desarrollo, lo más difícil y crítico será que se adapten. Todo el éxito depende mucho de la gente involucrada.
Agregaría técnicas de aislar y blindar el código legacy, para minizar los puntos de contacto, controlarlos, y facilitar el refactoring. Escribir una cantidad masiva e ingente de pruebas unitarias a medida que se va avanzando sobre el código y su comprensión. Poner todas las suposiciones y definiciones como pruebas unitarias.
Hay muy buena y abundante bibliografía sobre el tema, recomiendo aprovecharla, porque hay muchísima experiencia plasmada en textos que vale la pena reutilizar. Me viene a la mente el libro Clean Code y otro específico sobre Legacy Code (no recuerdo exactamente el título, es más no estoy seguro si era sobre Java o más bien sobre C++, pero tenía técnicas y experiencias muy útiles).
Y bueno, asesorarse mucho en stackoverflow y sus sitios. Y porqué no en JH :)
Tuve suerte, la aplicación no era muy grande y había gente a favor de rehacerlo entero :) Así que se rehizo y poco a poco se fue quitando tráfico de la versión anterior hasta que dejó de ser usada y se borró.
Convivo con uno de esos sistemas desde hace más de 10 años. El problema es que solo he podido hacer eso hasta ahora, convivir, porque de tocar en serio mejor ni hablamos.
Esas cosas de plantearse que tienen un problema, buscar a un experto, contratarlo y seguir sus consejos deben ser de otro planeta, porque en este llamado Ejspañía, ni de palo. Y eso que tuve que cambiarlo de plataforma (de un Unix a otro), de BBDD (de una propietaria a Oracle) y hasta hemos empezado a usar Linux hace unos meses.
Pero cada vez que he planteado empezar a usar una solución más racional a medio y largo plazo, la respuesta siempre es la misma virgencita, que me quede como estoy..
Con sus pegas, pero el sistema funciona, y ello a pesar de que quienes lo hicieron sabían medianamente de C y bastante poco de programación en Unix. Y ahora mismo hay un pastiche de aplicaciones en C, C++, Java y un montón de scripts que usan la korn shell y pequeñas utilidades para hacer cosas que, de otra manera, no se podrían hacer de forma sencilla (como menús que usan curses).
Algún día tendremos un disgusto, y entonces llegarán las prisas y los llantos, pero hasta entonces....
pues lo normal en estos casos: le echas un poco de tomate frito y queso y te las comes hasta que se acaben o hasta que se las pueda comer otro
Lo que iba haciendo en mi caso y sabiendas de que mi gestor me iba a mandar a tomar aire fresco en la puerta pues lo único que le importa es que se hicieran las cosas rápido para poder hacer más; lo único que podía hacer era dejar como estaba el núcleo de la aplicación e ir poco a poco cambiando el código por algo más correcto, desde la perspectiva de ingeniería del software y no decir nada. O sea que lo mejor que podía hacer era poner más horas de las que debía y aplicar técnica Stealh.
Estoy en desacuerdo con hacer pruebas unitarias .Es muy facil hacerlas entender que son y su importancia pero no su creación.Para crear pruebas unitarias se debe seguir una seria de practicas que no las siguieron.Estas practicas son tdd, refactoring,principios solid, mocking,crear codigo facil de entender.Y debido a eso crear pruebas unitarias es en la practica inutil.
Entonces la única opción es crear pruebas funcionales en el gui.Para luego ir poco a poco limpiando la mas grave y muy lentamente a planes a futuro crear pruebas unitarias
en conclusión es una perdida de tiempo crear pruebas de unitarias a un código legacy por que el código simplemente no es testeable y la única opción es crear pruebas funcionales
Yo empezaría de arriba a abajo: pruebas funcionales, agrupar la funcionalidad, y después, intentar modular esa funcionalidad, separar módulos de la aplicación....
Es decir, iría de lo funcional (la aplicación funciona) y después me iría a la programación (la calidad es mala). También es probable que la persona que hereda el código es crítica a nivel técnico, y a medida que vaya viendo un poco de luz, probablemente, su opininión vaya cambiando.
Me he encontrado aplicaciones complejas de mantener, y lo que procuro hacer, primero, es aprender a ejecutarlas, y después recorrerlas. Si tiene un análisis funcional definido estupendo, si no creo un plan de pruebas y ejecuto las pruebas para ver en que punto están. Y después, con paciencia (y si me deja la parte de gerencia) voy poco a poco mirando qué llamadas se realizan e intentando mejorar la parte técnica.
Para un técnico, es frustrante heredar código de baja calidad, para el gerente, que entiende de dinero, es el técnico el contratado y cualificado para buscar soluciones, y en cierta manera, aunque nos duela, su parte de razón lleva. Estoy de acuerdo con vosotros en que la calidad del código muchas veces no es la ideal.
Saludos cordiales,
Pues disfrutar y disfrutar y disfrutar.
Refactorizar a lo bestia una aplicacion compleja PERO QUE FUNCIONA (aunque regular a base de parches malamente anyadidos con los anyos) es una de las experiencias mas duras y placenteras que existen, el hecho de que no haya un mercado y gente especializada en este tipo de situaciones/aplicaciones demuestra la eterna mediocridad de este sector.
Ahora bien no se puede hacer de cualquier manera, guste o no tienes la sarten por el mango, si te piden que arregles "eso" en un par de dias mejor que no empieces, si te meten presion mejor que te vayas, si no tienes alguien siempre disponible para resolver dudas del negocio dejalo, y sin duda alguna si no te pagan bien porque es uno de los pocos trabajos en los que el beneficiario tiene que estar agradecido, porque estas salvando su negocio y porque lo que tienes que hacer es convertir una bazofia en un apetitoso plato no anyadir mas basura.
Ahora bien si esta hecho en un lenguaje dinamico a mi no me llameis, bueno actualmente no me llameis de todas formas :)
Aparte de salir huyendo si no te dan tiempo, lo primero que hay que hacer y que mucha gente se olvida o directamente no quiere hacer es hacer ingenería inversa de los requerimientos, por que en estos casos la documentación real ES el código y aunque las respuestas típicas incluyen "pero si todo el mundo sabe lo que hace", "para que vamos a documentar algo que ya funciona" etc... luego pasa lo que pasa.
Que cuando se rehace, descubres que no hace lo mismo que hacía antes en esos casos que no se contemplaron al principio y sólo se parchearon en código después etc. etc. y la gente se frustra, declara que la nueva versión es una mierda después de lo que ha costado y el proyecto entra en barrena.
Y no es tan aventurado afirmar que los que llevaron el código dos décadas no tienen conocimientos de ingeniería de software... son científicos sin ninguna educación formal en ese campo y los conoce personalmente, así que digo yo que sabrá lo que dice.
Estoy de acuerdo con lo de la ingenieria inversa, no hay otra, por eso he resaltado lo de "pero que funciona"
Casi sera mejor rehacerlo desde el principio y bien, o te querras cortar las venas.
Si decía que era arriesgado juzgar por el código que se ve no es por otra cosa que lo que he sufrido en mis carnes. El cliente cambia los requerimientos y convence al gestor de que es una nimiedad y le saca un presupuesto cerrado de 8h. Desde ese momento da absolutamente igual lo que argumentes. Son 8h y se debe entregar al día siguiente. Como mucho, si ni comes ni duermes podrás usar 16h extra que no cobraras.
Si esto ocurre una vez no pasa nada. Con el tiempo de otras ampliaciones o cambios podrás ir arreglándolo en modo stealth, como decía el compañero. Lo malo es que el gestor que hace esto no lo hace solo una vez y aunque consigue que la aplicación funcione, el coste en horas real para cada nuevo cambio se incrementa muchísimo al tener que ir añadiendo parches sobre parches cuando con un pequeño esfuerzo extra en cada cambio hubiera sido muy inferior al coste de cada cambio actual. Es la filosofía del pan para hoy y hambre para mañana.
Con los años asumes que lo mejor es enemigo de lo bueno, lamentablemente.
Lo unico que se me ocurre aconsejarle al autor del hilo es que no se obceque en entenderlo todo o se volverá loco. Mejor el cachito que resulte afectado cada vez, aunque sea una mierda.
Salut
Bueno, yo le gano por unas 50k lineas jeje. Tampoco son tantas.
Más que "ingeniería del software" a esto me gusta más llamarlo "arqueología del software", por aquello de tener que entender los vestigios que dejaron antiguas civilizaciones jeje.
En estos casos creo que en primer lugar lo que hay que hacer es intentar evaluar cual es el estado de salud del enfermo, yo para medir este estado empeze haciendo varias cosas:
- Revisar el estado del build y arreglarlo, lo primero hay que tener una forma racional de construir el software a partir de los fuentes. En nuestro caso usaban maven, no estaba la cosa muy mal, faltaba solucionar algunos temas con dependencias que se copiaban "a pelo" al .m2 (y esto descrito en un documento...) y algún pequeño arreglo más, como por ejemplo borrar decenas de test que no pasaban porque al no tener un entorno de CI estaban más que obsoletos.
- montar un entorno de CI para que al menos mantener el build sano (esto cuesta media hora),
- montar un sonar para sacar una métricas de como esta el asunto. Y el asunto estaba mal, +10% de duplciación, errores bastante gordos en el manejo de excepciones aqui y alla, complejidad ciclomatica para hacerselo mirar,,, esto de paso sirve para tener alguna forma de justificar ante el que paga el trabajo de rediseño o el coste de añadir hasta la caracteristica más tonta. (y eso que el sonar no evaluaba las toneladas de javascript con framework propio de widgets incluido).
En mi caso más que decir "no tenían ni idea de ingeniería del software" lo que hubiera preferido es que esta gente no hubiera leido nunca un libro sobre diseño. Barroco es el termino más adecuado que se me ocurre para definir la arquitectura del invento. Un cluster, colas en un sistema de cloud, procesos de backoffice (algo tipo he visto una conferencia de CQRS voy a probarlo a ver que tal aunque no me haga falta pa na), webservices proxys de otros webservices que no sirvén para nada, AOP para temas transversales como "seguridad" que hacen que sea un milagro entender donde y como se aplica la seguridad en el sistema, el sindrome de 1interfaz - 1implementación (esos LoQueSeaImpl...), un 20/30% del código sin exagerar compuesto de métodos get&set (esto es encapsulación claro que si, y luego desde un servicios pones objeto().getX().getA().getB()... ains cuanto daño hacen algunos framegüorks).
Una vez echo esto, gracias a que desde el negocio se requería un rediseño casi completo de la web (visual y funcionalmente) empezamos de 0 (bendito sea dios) al menos la parte web, los procesos de backoffice los seguimos manteniendo y los iremos sustituyendo uno por uno ahora que varios meses después tenemos un conocimiento mucho mayor del negocio y del sistema.
A jose maría seguro que le encanta esto, la web nueva esta completamente echa en groovy, hemos pasado de 100k lineas a menos de 20k, el código ahora podemos manejarlo (en parte porque es mucho más sencillo, en parte porque es nuestro obviamente), y tenemos una cobertura de test que nos permite vivir más o menos tranquilos.
De todos modos, los preocupante de todo esto es que situaciones como esta son la norma, yo lo que no he visto casi nunca es un proyecto de cierta envergadura que no se convierta en algo cuasi inmantenible comido por su propia complejidad. Cada día tengo más claro que esto del diseño de software es simplemente una lucha diaria contra la complejidad, no hay nada más importante que mantener las cosas sencillas. No hacemos algoritmos hipercomplejos para la NASA los proyectos se van siempre a la porra por lo mismo, no sabemos controlar la complejidad cuando un proyecto crece.
Veo Alfredo que no te atreves a decir cual era el "framegüork" maravilloso que había detrás, yo creo que sí lo se (y no porque me lo hayas dicho sino porque te conozco un poco) y no porque el framework sea "malo" sino por los mega-abusos que suelen aplicarse a algunas buenas ideas.
"no sabemos controlar la complejidad cuando un proyecto crece"
Cuanta razón, cuanta razón... vivimos en una "industria" (por llamarla de alguna manera) obsesionada por las malditas herramientas, CHORRADAS que en la mayoría de las veces se aprenden en una maldita semana, cuando el verdadero (y trágico) problema es la GESTIÓN DE LA COMPLEJIDAD.
Yo no se si soy buen programador o no, se que los hay mejores que yo, aunque algunos de ellos se dejen llevar por la chorrada de que la herencia es mala (toma indirecta), y NO hablo de frameworks. Pero lo que siempre he constatado todas las veces que he hecho una entrevista de trabajo es que NUNCA me han dicho "enséñame algo de código tuyo" o "he estado viendo código tuyo" y mira que tengo MEGABYTES de código fuente público (y más que podría sacar pero no me apetece y porque cada vez creo menos en ello), a lo máximo que llegamos es hacer es un estúpido examencito de cosas que se pueden aprender en media hora y que puede tener algún valor para un junior pero poco más, todo esto muestra el PROFUNDO ERROR de concepto que tenemos en "la industria" y es la casi ausencia de Alfredos Casados, porque no se evalúa el AlfredoCasado-level sino que se evalúa el número de "meses-Spring" y así nos va.
El problema es cuando le toca a uno evaluar y preguntas "puedes enseñarme algo de código" y la respuesta es "no tengo" y te tienes que fiar de siglas, años y colorines.
Lo de herencia o no herencia, dinamico o estatico, en el fondo son pequeñas decisiones de diseño, y probablemente todas sean correctas si luego se aplican con criterio, son distintas herramientas y bien usadas todas nos pueden llevar a buen puerto, no hay soluciones únicas.
Lo de la "industria" pues ya sabemos lo que hay, en una industria sana alguien con una experiencia como la mia debería ser uno de los miembros del equipo con menos experiencia y no al contrario.
Por ejemplo, el otro día hablaba con alguien sobre el sueldo medio que tienen los desarrolladores de dispositivos moviles (ios, android) y como no se puede buscar a alguien con más de 2 o 3 años con esas tecnologías (es lo que tiene que no existieran antes) pues claro, a gente con sólo 2 o 3 años se les paga poco. A nadie se le ha ocurrido que desarrollar para esas plataformas es simplemente desarrollar software y que lo que necesitas es un desarrollador de software con experiencia y punto, no un "desarrollador movil". Es justo lo que dices, obsesión por las herramientas en lugar de por las practicas y los conocimientos de base.
Sobre sistemas legacy
Hace un tiempo, armé una propuesta para un sistema Cobol antiguo (y en este caso entiéndase sistema por un conjunto bastante importante de programas independientes).
Mi aproximación estaba en avanzar por capas de arquitectura en vez de hacerlo por línea de negocio, que es el enfoque más "tradicional".
Esto es en 3 fases.
Fase 1.
Sacarle a cobol el almacenamiento en bases propias y mandarlo a trabajar contra DB relacionales, pero sin tocar las procedure division. Esto incluye obligatoriamente el rediseño y la migración de la base de conocimiento.
Fase 2.
Reemplazar las interfaces de usuario Cobol por web y RPC pero dejar las aplicaciones Cobol como reglas de negocio para estas interfaces, a manera de EJB's.
En este punto, ya es posible encarar cualquier nuevo requerimiento por fuera de Cobol.
Fase 3.
Ahora sí, se toma cada línea de negocio como un caso de uso independiente, y se reemplazan estos programas cobol por un nuevo desarrollo (sean estos en el ERP comercial o en los AS de las instalaciones ) un caso de uso a la vez. Y allí donde el costo de rediseño, vida útil de la necesidad o la cantidad de usuarios que tiene no justifique la inversión se deja el Cobol, pero ya integrado al nuevo contexto.
Para poder demostrar el porqué una aproximación por capas de arquitectura es más sana que una por línea de negocio (para un sistema de esta envergadura), tuve que investigar bastante (y también molestar a muchos conocidos :o) ) pero al final pude demostrar sus beneficios, incluso hasta desde el punto de vista de la sicología de los usuarios.
Lamentablemente, esta propuesta no fue aceptada.
Aun así, me sigue pareciendo la manera más sana de encarar la migración de un sistema antiguo ( pero que sigue haciendo lo que tiene que hacer) y al mismo tiempo garantizar la migración de la base de conocimiento, la continuidad en la coherencia de las reglas de negocios y disminuir la resistencia natural al cambio por parte de los usuarios.
Un saludo.
alfredocasado: "A nadie se le ha ocurrido que desarrollar para esas plataformas es simplemente desarrollar software y que lo que necesitas es un desarrollador de software con experiencia y punto, no un "desarrollador movil". Es justo lo que dices, obsesión por las herramientas en lugar de por las practicas y los conocimientos de base."
No puedo estar más de acuerdo y sin ir más lejos me pillas MUY cerca de ese tema, en mi empresa seguimos en el proceso de selección de un programador iOS, formo parte de ese proceso de selección (lo cual no significa que tenga la última palabra ni en la persona ni en el salario), a mi personalmente lo único que me importa es tener CONFIANZA y la capacidad de gestionar la complejidad, me preocupa mucho más que cuantos años utilizando la herramienta X, es más creo firmemente en que un buen programador Java puede ser un buen programador Objective-C en relativamente poco tiempo (aunque en mi opinión más que los frameworks la barrera de entrada más fuerte es el lenguaje).
El problema es que en este puesto a mi pesar no tenemos ese tiempo, pero la "experiencia" puesta en un C.V. programando iOS no me da garantías de ser cuidadoso, de ser SOLID (aunque no soy un fundamentalista y creo en la contaminación necesaria), de tener el mandamiento "refactorizarás siempre que sea necesario", de obedecer la regla de "no dejarás que los hilos hagan indeterminista tu programa", de testear lo más que puedas, de amar la POO sobre todas las cosas, de no cegarse por las herramientas, de ser un obseso del control, de dejarse llevar por el sentido común y no por las modas, de tener la máxima "da igual lo cutre y lo mal pagado que sea tu trabajo tu buen hacer está por encima de todas las cosas"....
¿cómo se miden esas cosas? ¿en años programando en X o usando la herramienta Y?
Cuando has visto que uno de los mejores técnicos en iOS de España suda tinta ¿cómo valoras que alguien puede estar en el mismo nivel? ¿seguro que sólo con los años?
Y respecto al pagar poco ¿tú crees que una empresa que se precie que se juega la satisfacción de usuarios reales, cuya experiencia de usuario va *directamente* ligada a ventas puede ser cutre y por ahorrar cuatro euros poner en riesgo un canal de ventas?
Si compras confianza tienes que pagarla (aunque obviamente hay un límite).
Perdón por la publi pero es que viene taaan a cuento.
Este hilo me recuerda este artículo de Joel on Software:
http://discuss.joelonsoftware.com/default.asp?joel.3.219431
Hola efrigerio , leyendo tu comentario me asoma una sonrisa porque me he visto con lo mismo … y peor.
En tu caso parce que la versión del MAINFRAME te permitía consumir los datos de una base relacional desde el COBOL, en mi caso es tan antiguo, que solo permite “tablas planas” o ficheros VSAM.
A los pobres diablos que se vean con algo parecido les recomiendo encarecidamente los productos de código abierto de la compañía LEGSTAR. A saber, te facilitan unos programas COBOL o NATURAL que utilizan el servidor de transacciones del MAINFRAME y que pueden interactuar de forma transparente y en las dos direcciones con tus clases Java, mediante proxy o los conectores para MULEESB, JBOSS ESB etc. Lo que se intercambia es el COPY-BOOK del módulo NATURAL/COBOL que se trasforma a un simple POJO y viceversa.
Otra recomendación muy encarecida es que se instalen estos módulos de LEGSTAR en “una partición de sistema” del MAINFRAME que tengan acceso a datos y programas de las otras particiones que quieras utilizar (vienen a ser servidores virtuales de hace 30 años, con su espacio, memoria y programas disponibles), así te garantizas el servicio evitando los “parones” de mantenimiento.
En fin, en mi caso tampoco aceptaron y prefirieron hacer las migraciones manuales, migrando la lógica a PLSLQ !!!, para poder trabajar con el DESIGNER … en fin, que mi vida es muy triste y ya estoy buscando curro en otro lado ;-) .
Creo que aquí hay demasiados académicos. Una cosa es que te pongan un proyecto en el que tienes que evolucionar, o rehacer desde cero la funcionalidad de un Sistema viejo, y la otra es que llegues nuevo a una empresa y te digan que debes hacerte cargo de ese Sistema viejo y atender los requerimientos de los usuarios a como vayan cayendo. Cuando te enfrentas al último caso, que es lo que le sucedió al que hizo el comentario inicial (el de las 200 mil líneas de código espagueti), no queda más que hacer los nuevos cambios de la mejor manera posible y utilizando una metodología que se ajuste a lo que hay.
Si el código tiene más de 2 décadas, de seguro no es Java y muy posiblemente tampoco es Orientado a Objetos. Estás hablando de Cobol o RPG, o algún lenguaje 4GL si topaste con suerte. Así que todas esas nuevas metodologías no son más que pendejadas si las aplicas a este contexto.
En otras palabras no te queda más que relajarte y disfrutarlo.
Mi primer trabajo.....era traducir código TCL a DUP (lenguajes muy específicos de telecomunicacion). Después de DUP a CGDC. Posteriormente en otro trabajo, me encontré con código heredado, esta vez en programación web, Javascript y PHP usando JSON. Además de una página web con el consiguiente PHP, Javascript y HTML.
Por más que vas aprendiendo...siempre es difícil la lectura, comprensión y traducción de código espaguetti.
Mas por que a las empresas les interesan los resultados, no la mantenibilidad, escalabilidad o fácil lectura del código.