Refinamiento continuo

Antes de comenzar una nueva fase de desarrollo, conviene dedicar algo de tiempo a mejorar todo lo que ya hay.

La construcción de una pieza de código de calidad es un proceso incremental y nunca, absolutamente nunca, lo primero que escribes, aunque funcione, tiene la calidad que debe tener para asegurar su mantenibilidad.

Es algo que comienza para mí a ser recurrente: encontrarme analizando proyectos que por alguna razón, terminan siendo difíciles o imposibles de seguir evolucionando. No importa la tecnología que se use, aunque hay algunas que tradicionalmente han provocado una mayor cantidad de proyectos muy corruptos, quiero decir, proyectos que terminan siendo reescritos desde cero. PHP, por ejemplo, tiende a esto, pero no por el lenguaje en sí, sino porque su curva de aprendizaje es tan fácil que en poco tiempo alguien que se inicia en el mundo de la programación consigue obtener algún resultado sin siquiera necesidad de programar orientado a objetos, y, con el tiempo, la aplicación va creciendo y creciendo sin consolidar principios de diseño, buenas prácticas, una gestión de la configuración correcta, código limpio y... O sea, una auténtica pesadilla. La orientación a objetos tiende a forzar un diseño algo mejor, aunque este tema da mucho de sí.

Se sospecha en un primer vistazo si el diseño ha sido cuidado y revisado (si es que existe "diseño" como tal, cuando no un sistema excesivamente monolítico), así como la estructura y calidad del código de cada método.

Ocurre exactamente igual que cuando escribes un relato: primero comienzas con un borrador (y sí, "funciona", en el sentido de que transmites la idea que quieres dar a conocer). Si le das una pasada vas a encontrar seguramente algún error de puntuación, ortográfico o gramatical, y con toda seguridad, leerás párrafos que en esa segunda lectura encuentras el modo de mejorarlos. En una tercera revisión vuelve a ocurrir lo mismo, hasta que llega un momento en que la intuyes que ya calidad de lo que has escrito está a la altura de tus expectativas, quizá en la quinta, sexta o décima lectura de correción, y más aún si son otros los que leen tu texto y encuentra typos sutiles que tú has pasado por alto.

En software es igual, con la diferencia de que estas revisiones afectan tanto a la estructura del código (diseño) como a sus defectos (excesivo acoplamiento, baja cohesión, duplicidades, violación de principios de diseño, código díficil de entender, pruebas insuficientes, etc.). La cuestión es, ¿para qué me debo preocupar de esto, si funciona mi aplicación? Mmmmm

Si desarrollas una aplicación que nunca va a tener que ser cambiada, hasta vale entregarla con todos los defectos que se te puedan ocurrir, pero esto rara vez ocurre, porque en la mayoría de los casos todos los proyectos sufrirán modificaciones en mayor o menor medida.

Cuántas aplicaciones he visto ya que son una simple extensión de un núcleo excesivamente monolítico... hasta que llega el momento en que ya no soporta más cambios y hay que tirarla a la basura y comenzar de cero, para frutración (o alivio, quien sabe) de los desarrolladores, y varapalo para el negocio que incurre en sobrecostes, y además algún responsable que tratará de escurrir el bulto como sea.

La forma de evitar esto es refinar continuamente la aplicación en la que se trabaja, tratando de mejorar todos aquellos aspectos que en ingeniería del software sabemos que aportan calidad al código. Hablo de calidad en el sentido de generar una aplicación mantenible, que soporta pruebas automatizadas y que es fácil de modificar y de incluir cambios.

Es sorprendente que algunos de estos refinamientos son triviales, sencillos, se realizan en poco tiempo; e igualmente sorprendente es el beneficio que reportan a medio y largo plazo. Por poner algunos ejemplos:

• Comprobar si el código cumple con todas las buenas prácticas de clean code (buenos nombres, indentaciones correctas, clases cortas, comentarios limitados a lo necesario).
• Comprobar la cohesión de las clases para generar un buen diseño.
• ¿Se cumplen correctamente los principios SOLID?
• Refactorizar pequeñas partes de la aplicación para mejorar su diseño y aumentar la simplicidad.
• Darle una vuelta a aquella lógica de negocio más compleja que se pueda simplificar en la medida de lo posible.
• Revisar si se puede mejorar aún más el procedimiento de despliegue.
• etc.

Es buena idea antes de comenzar una nueva fase de desarrollo, dedicar algo de tiempo a todo lo anterior; al hacerlo así, es más que probable que favorezca que necesitemos de menos tiempo para incorporar las nuevas características sobre las que tenemos que trabajar.