Legacy Code

Por Rafael Gómez Blanes

¿Cómo mejorar de forma sencilla y poco a poco código que ha crecido demasiado rápido y quizá de forma desorganizada? ¿Cómo modernizar una aplicación "heredada"? En catorce pasos, Rafael Gómez Blanes muestra un método fácil con el que "modernizar" con el menor esfuerzo posible un proyecto software que presenta déficit de buen diseño y con demasiada deuda técnica.
Por el autor entre otros de El Libro Negro del Programador, The Coder Habits y El Libro Práctico del Programador Ágil, entre otros.

• Idioma: Español
• Editorial: Rafael Gómez Blanes
• Fecha de lanzamiento: 1 dic 2020

Rafael Gómez Blanes

Rafael Gómez Blanes es Ingeniero Informático por la Universidad de Sevilla (España). Infoemprendedor, ha trabajado en proyectos software internacionales relacionados con el sector eléctrico. Desarrollador profesional desde el año 1998, es experto en clean code y todas aquellas prácticas metodológicas que incrementan la productividad, mejorando la calidad del software generado. Evangelista de software ágil, dirige actualmente un equipo de desarrollo en una compañía de ingeniería realizando productos para la gestión de smart meters y su despliegue en la nube en modo SaaS (software as a service).

Vista previa del libro

{ Legacy Code }

Cómo modernizar en catorce pasos código heredado

o proyectos software que han crecido demasiado rápido

Rafael Gómez Blanes

Primera edición - Diciembre de 2020 - #01#

Rafael Gómez Blanes - Copyright © 2020

Todos los derechos reservados

Legacy Code

Cómo modernizar en catorce pasos código heredado

o proyectos software que han crecido demasiado rápido

www.rafablanes.com

ISBN: 9798574200155

Editado por Hub de Libros

www.hubdelibros.com

A mis padres, hermana y mis hijas, Luna y Beatriz

A mi pareja Mercedes

A todos aquellos autores que tanto me han enseñado

{ Introducción }

―

Lo he visto en demasiadas ocasiones: proyectos y aplicaciones software que han crecido de un modo descontrolado hasta que llega el punto en que modificar algo, añadir una nueva funcionalidad o depurar un simple error, se convierte en una tortura y una inversión demasiado alta en tiempo (= dinero).

Por extraño que parezca, en software esto es relativamente normal que ocurra.

Y también he visto lo contrario, afortunadamente: sistemas de gran tamaño que han sido bien diseñados desde el comienzo, con numerosas iteraciones de limpieza y mejora de diseño y que hoy día están en producción en diferentes clientes con un mínimo mantenimiento, presentando una facilidad pasmosa de añadir nueva funcionalidad o modificar la existente.

¿Cómo se llega a la primera situación y qué hay que hacer para conseguir la segunda?

Las buenas prácticas de desarrollo de software están bien descritas en nuestra industria desde hace mucho tiempo y he hablado de ellas en varios de mis libros (como «El Libro Negro del Programador», «El Libro Práctico del Programador Ágil», «The Coder Habits», etc), existiendo además autores mucho más reputados que yo y a los que sigo, admiro y recomiendo.

Las razones por las que un proyecto software se corrompe o termina siendo algo de tipo espagueti, siempre son múltiples, y no vamos a caer en el error de demonizar al desarrollador (junior o sénior) encargado de ese resultado algo desastroso, ni tampoco a las condiciones de trabajo que impone el responsable del proyecto (que tiene sus propias presiones), porque la experiencia me ha demostrado que todo cuenta y que tan importante es la habilidad y buena intención del programador como el entorno organizativo para conseguir un resultado de calidad.

Con el tiempo, y después de haber trabajado en más proyectos de los que puedo recordar, se va desarrollando cierta intuición, de modo que sabes las consecuencias sutiles a largo plazo de hacer algo de un modo concreto, como indican perfectamente los «bad smells» (malos olores) en el código.

Conoces de primera mano que lo que mata cualquier proyecto software es ir dejando de lado ese tipo de detalles que, con el tiempo, se van acumulando de tal forma que su efecto negativo termina siendo exponencial aumentando el volumen de una gran bola de nieve que tarde o temprano caerá por su propio peso, esto es: proyectos inmantenibles que se tiran a la basura (y que en el mejor de los casos se hacen de nuevo), la imposibilidad de introducir cambios o que presentan errores por todos lados.

Si en tu código… existen funciones, métodos y clases demasiado largos, no se huele nada que implique cierto diseño, no se aprecian claramente los principios de desarrollo S.O.L.I.D., ni inyección de dependencias, todo parece demasiado acoplado (dependencias) y hasta es imposible siquiera plantear una batería mínima de tests unitarios, corregir un error es un suplicio, te encuentras con demasiadas sentencias «if, if, if» anidadas y comentarios aclaratorios por todos lados y hasta con código muerto, por poner solo algunos ejemplos, entonces lo que tienes entre manos es una patata caliente si lo que se quiere es mantener un proyecto así y añadir más funcionalidad a un coste razonable.

Cuando un edificio está en ruinas, difícil (y costoso) reformarlo. No obstante, en software podemos mejorar el edificio y hasta conseguir que resplandezca de nuevo si es necesario y si se ha evaluado que merece la pena.

Hay ocasiones aceptables en las que existe un crecimiento descontrolado y poco riguroso de una aplicación: cuando se trabaja en un prototipo, cuando hay que correr por urgencias del negocio (sabiendo que habrá tiempo más adelante para mejorar esto y aquello), o sencillamente cuando estás jugando en tu tiempo libre y tan solo quieres experimentar y aprender algo nuevo.

No obstante, llegados al punto anterior en el que existe algo que no está del todo bien hecho y que tiene que seguir adelante como