2.3 Intervenciones quirúrgicas

Se suele esperar que un cirujano haga la intervención de forma correcta, precisa y lo menos intrusiva posible para que la posterior recuperación sea más rápida y efectiva. En nuestro caso, seguimos esta filosofía, puesto que muchas veces hacemos intervenciones increíbles a código abierto. En este capítulo hablaré de situaciones y tipos de proyectos que nos solemos encontrar cuando tenemos que intervenir en sistemas desarrollados por terceros.

Menos es más

La experiencia te puede ayudar a mejorar tu ojo clínico, es decir, la capacidad de poder arreglar o modificar cosas sin siquiera tener que saber qué hacen o cómo lo hacen porque solo te centras en el problema a resolver, sin preocuparte del resto que sí funciona correctamente. Dicho de otra forma, no necesitas revisarlo todo, sino que te puedes imaginar por dónde pueden ir los tiros en base a problemas similares que has resuelto previamente, por ejemplo, que falte instalar o importar una librería para que el proyecto funcione. Aunque, desgraciadamente, en muchísimas ocasiones las cosas no son tan fáciles y tienes que picar piedra (realmente dura).

Al contrario de lo que algunos creen, es habitual que los desarrolladores solo tengan experiencia con pequeñas partes de las aplicaciones y no con su totalidad, mayormente en el caso de aplicaciones grandes y sobre todo cuando se trata de sistemas desarrollados por terceros. En otras palabras, cuanto más grande sea un sistema, menos desarrolladores lo conocerán completamente y, si además tenemos en cuenta la alta rotación dentro del sector, esto se acentúa todavía más.

Así pues, cuando hay que arreglar bugs o hacer cambios en una aplicación hecha por otras personas y que ya está en producción, se pueden adoptar distintos enfoques en función de lo que nos encontremos y los recursos que tengamos disponibles. El caso ideal es que nos encontremos con código bien hecho y estructurado. En este caso, simplemente haremos los mínimos cambios necesarios siguiendo las buenas prácticas y ya está. Por desgracia, muchas veces la realidad es muy diferente y nos encontramos con proyectos en un estado lamentable. En estos casos tenemos varias opciones:

1. No decir nada y parchear el código encima, dejando lo que había tal cual estaba.
2. Rehacer lo que estaba mal sin avisar a nadie, asumiendo todos los riesgos que ello conlleva.
3. Informar a los responsables de lo que nos hemos encontrado y dejar que tomen ellos la decisión de refactorizar el código o solo parchearlo encima, con lo que se quería hacer inicialmente.
4. Recomendar descartar el proyecto actual y hacerlo nuevo desde cero.

La primera opción puede ser la más rápida a corto plazo, pero si todas las personas que intervienen en el proyecto hacen lo mismo, al final va a haber tal bola de parches que el proyecto se va a convertir en un Frankenstein imposible de mantener. En proyectos «vivos» suele ser una muy mala opción. No obstante, en proyectos viejos donde prácticamente no se hacen evolutivos y donde no hay presupuesto, esta es muchas veces la opción elegida.

La segunda opción puede ser un auténtico suicidio. Refactorizar código mal hecho conlleva muchos riesgos, ya que a veces hay chapuzas que parecen no tener sentido, pero que trabajando en conjunto hacen que el sistema funcione (a trompicones) porque se compensan o se complementan entre ellas. Con lo cual no recomiendo hacer esto porque, si luego las cosas van mal, te van a señalar a ti como el responsable y además te van a echar en cara que «has tardado mucho» y que «ahora esto no funciona». Hay gente que tiene una tendencia innata a rehacer lo de los demás porque creen que lo podrían hacer mejor y probablemente sea cierto, pero hay que hacer un análisis de riesgos antes de enfangarse.

La tercera opción es más sensata que las dos primeras, bajo mi punto de vista, porque se da a conocer el estado real del proyecto y se deja la opción de mejorar su estado de salud, previa planificación y asignación de recursos. No obstante, hay que intentar aplicar la «ley del mínimo esfuerzo, máximo rendimiento», en el sentido de que, si hay cosas que se pueden aprovechar, se aprovechan. No hay que tirarlo todo, a menos que no hacerlo suponga más trabajo. Hay que hacerlo lo mejor posible, pero sin dejar la piel en el intento. Por ejemplo, recuerdo un proyecto en el que se optó por investigar cómo estaba hecho, documentarlo (que no era poco) haciendo diagramas de las complejas e innecesarias llamadas entre componentes, etc., y refactorizarlo solo parcialmente. Más vale eso que nada, ahora al menos saben de qué pie cojea y también saben por dónde pasan las arterias y las venas de esa extraña criatura.

La cuarta opción es sin duda la más drástica de todas, pero a veces es la mejor debido a que el proyecto está hecho un auténtico desastre y no hay por dónde cogerlo, las tecnologías con las que fue desarrollado han quedado obsoletas o los cambios que se quieren introducir no cuadran por ningún lado con la arquitectura actual del proyecto. A corto plazo puede parecer la más lenta y la más arriesgada, pero en ocasiones es lo mejor que podemos hacer, ya que tratar de mantener ese viejo proyecto con vida va a ser muy costoso a largo plazo y seguro que los nuevos cambios van a contribuir a incrementar aún más la deuda técnica, que ya arrastra desde hace tiempo. Por lo tanto, en estos casos no hace falta alargar la agonía del proyecto y es mejor que pueda morir dignamente y descansar en paz, dejando paso a una nueva generación.

Proyectos Frankenstein

Los proyectos Frankenstein son esos proyectos que están mal hechos, no suelen tener gran estabilidad y tampoco suelen tener contemplados casos fuera de los estrictamente más comunes (solo «funciona» el happy path), con lo cual es fácil encontrar errores con poco esfuerzo. Muchas veces contienen código copiado y pegado de otros proyectos, sin mucho criterio. Ojo, es muy diferente reaprovechar componentes a dedicarse a copiar código de otros sitios, sin preocuparse en ningún momento por las licencias de software ni nada por el estilo. Además, es muy habitual encontrar problemas en partes de código «copiadas de Internet» y que no se sabe exactamente qué hacen, porque en muchas ocasiones son complejas y difíciles de entender.

Este tipo de proyectos no solo se crean a base de juntar código de distintos sitios, sino que también los puede crear una sola persona con su propio código, simplemente poniendo el foco en hacer las cosas rápido y/o de cualquier manera. Aunque sí es cierto que en muchas ocasiones son la obra de más de un creador y además se potencian entre ellos. Son como creaciones de científicos locos haciendo experimentos raros para ver qué sucederá cuando se pulse el botón y cobren vida.

Las fulanas

Los proyectos fulanas son aquellos en los que todos han metido mano, pero siempre de forma temporal. Normalmente los modifica una persona (o grupo de personas), luego otra y así sucesivamente. En muchas ocasiones no hay documentación, test ni ningún tipo de traspaso de conocimientos entre las personas que van a manosear el proyecto.

El resultado suele acabar en desastre porque en cada traspaso se pierde conocimiento, por muy bien que se haga. En teoría, nadie sabe mejor cómo funciona algo que el que efectivamente lo ha parido. A veces estos proyectos incluso rebotan sin un orden definido, es decir, lo empieza Juan, luego pasa a Pepe, después lo hereda Manolo, para después volver a Pepe y así sucesivamente. Cada uno modifica cosas haciendo lo que puede, sin saber ni entender bien qué ha hecho cada uno de los anteriores, ni por qué. Esto, en el mejor de los casos, puede llevar a duplicidades de código y falta de rigurosidad, pero normalmente va asociado a más bugs.

Hay que entender que un proyecto de software no es una patata caliente que se pueda pasar de mano en mano. Siempre he dicho que programar es un arte, ¿te imaginas pervertir un cuadro de esta manera? Un cuadro pintado por varios pintores que se lo van pasando de uno a otro, donde cada uno usa su propio estilo… ¡Menudo desastre!

La tradición mata

Dicen que la tradición es cultura, pero en ocasiones simplemente mata. El hecho de que algo se haya realizado siempre de una determinada manera no significa que esa forma sea la correcta. En múltiples ocasiones cuando he preguntado el motivo de hacer algo de una forma determinada la respuesta ha sido: «Siempre se ha hecho así». ¿En serio?

Estamos de acuerdo en que los cambios conllevan riesgo y que, si no vas a ganar nada, entonces no vale la pena intentarlo. Pero un cambio supuestamente a mejor, además de los propios riesgos, también brinda nuevas oportunidades. Por ejemplo, no puede ser que haya gente que despliegue los proyectos como lo hacía hace veinte años, con el argumento de que se ha hecho así toda la vida y funciona.

Recuerda que la cirugía ha evolucionado mucho en los últimos años y cada vez las técnicas son menos intrusivas y se obtienen mejores resultados. De hecho, muchas de las técnicas que antes se consideraban buenas, hoy simplemente no se aceptarían como opción o incluso serían ilegales.