Refactorizar una aplicación legacy. Parte I: Spaghettis y POO
En menor o mayor medida todos los que nos dedicamos a la programación (no sólo web), nos hemos encontrado con el problema de tener que enfrentarnos a una aplicación legacy.
El concepto legacy (legado en español) se refiere principalmente a un código que está obsoleto, desactualizado, pero que sigue siendo usado a día de hoy por el usuario final.
Este código no siempre viene de la mano de otro profesional. A veces he tenido que refactorizar código creado por mí mismo y que conforme pasa el tiempo (y adquiero nuevos conocimientos) me voy dando cuenta de que en su momento no utilizaba las mejores prácticas para programar una aplicación que sea lo más fácilmente mantenible o escalable.
El caso de estudio ¶
Como bien sabéis lo mío es más el backend, así que en este artículo vamos a dejar el frontend de un lado.
El caso que os presento se ha llevado a la máxima simplicidad para que se vean claros los conceptos, pero estoy seguro que muchos de vosotros os habéis enfrentado a algún caso similar.
Vamos a ponernos en la tesitura de que tenemos una pequeña aplicación que permite hacer login y que gestiona un directorio de contactos con datos no muy complejos: nombre, dirección, telefono, e-mail, etc. Los campos no son muchos, pero si que tenemos una buena cantidad de registros, alrededor de unos mil.
El lenguaje que suelo utilizar es PHP, así que veréis que esta es la extensión de los archivos que voy a pasar a describir, aunque esto bien se puede extrapolar a cualquier lenguaje.
En el raiz de la aplicación nos encontramos los siguientes archivos:
- contactos.php: contiene un listado de contactos.
- annadir.php: es utilizado para añadir clientes.
- borrar.php: usado para borrar clientes.
- modificar.php: se utiliza para la modificación de clientes.
- funciones.php: declaración de funciones que utiliza la aplicación: cambio de formatos de fecha, funciones de cadena propias, etc.
La unión de todos estos archivos se realiza con includes que van en el principio de cada una de las páginas. Tenemos que agradecer que todos los archivos están al mismo nivel ;).
Todavía nos estamos enfrentando a un código que contiene algo de abstracción pero más de uno seguro que se ha encontrado toda la funcionalidad de estos ficheros incluidos en un sólo archivo funciones.php.
¿o me equivoco?
Todo esto viene aderezado con muchisimos ataques a la base de datos con funciones mysql_query. Esta función, para quien no esté familiarizado con PHP, es una función que se encuentra deprecada desde la version 5.5.0 de PHP y es altamente peligrosa debida a los famosos ataques Mysql injection.
Ni que decir tiene, que los archivos.php que muestran HTML por pantalla tienen mezclados el código HTML con el de PHP.
Todo un mar de etiquetas <?php ?>
en las que nadar hasta el infinito y más allá.
Por último señalar que el código está escrito en procedural y no se ha declarado ni una clase en ninguno de los archivos. La programación orientada a objetos aquí no existe.
Los spaghettis y la Programación Orientada a Objetos ¶
Tenemos que tener en cuenta que nos estamos enfretando a una aplicación muy simple que solo trabaja con una entidad: los contactos; pero si nunca os habéis enfrentado a una aplicación legacy puesta en producción (con varias entidades interaccionando), os puedo asegurar que esto se convierte en una selva llena de código (en este caso de lianas), muy difícil de seguir. Es lo que se llama Spaghetti code.
Imaginaos un plato de spaghetti e intentad seguir uno sólo de esos spaghettis con la vista. Sí, no podéis.
Para poder deshacer este laberinto de código debemos centrarnos principalmente en tres buenas prácticas:
- Separación de intereses: cada cosa está en su sitio y preferiblemente en su archivo. Tenemos que intentar no ubicar todas las funcionalidades de entidades separadas en un sólo archivo.
- Desacoplar responsabilidades: cada elemento tiene su funcionalidad y no podemos delegar acciones de unas entidades en otras. Por ejemplo: un típico caso es el de un Blog, desde la entidad de comentarios no deberíamos realizar una consulta a base de datos en busca del nombre del autor del mismo. Para eso tenemos el bloque de autores o usuarios.
- Buscar constantemente código repetido: Si hay una señal inequívoca de que no estamos haciendo algo todo bien, es cuando repetimos bloques de código a lo largo de nuestra aplicación. Tener código repetido en nuestra aplicación hace a la misma difícil de mantener. Imaginaos volver al mismo código meses después y tener que cambiar algo en uno de esos bloques repetidos, tendríamos que buscar todos esos bloques para cambiar el dato.
Una de las mejores formas de cumplir estas buenas prácticas es utilizar la programación orientada a objetos.
Sea cuál sea el lenguaje que utilicemos, siempre tenemos la opción de programar con esta lógica. Es la mejor forma de mantener un orden.
¡Modelo Vista Controlador al rescate! ¶
La arquitectura Modelo Vista Controlador viene para poner un poco de orden en esto que llaman ‘big ball of mud’ (gran bola de lodo), y es que esta arquitectura permite escribir un código en el que la abstracción (cada cual tiene su responsabilidad) y el fácil mantenimiento, están a la cabeza de la felicidad de codificar :).
¡Y como no! El modelo vista controlador está totalmente orientado a objetos.
Esta arquitectura comprende:
- Modelo: que incluye todas las entidades de nuestra aplicación (en este caso los contactos) y los ataques a la base de datos.
- Vista: plantillas HTML dinámicas donde se muestra la información al usuario.
- Controlador: que se encarga de recibir las peticiones HTTP (en aplicaciones web), de devolver respuestas y orquestar lo que ocurre en medio de este proceso.
Hay muchos ejemplos según el lenguaje de programación. En PHP tenemos Laravel, en JavaScript esta implementación se ve en AngularJS, web2py en Python, etc. Aunque este modelo no está estrechamente ligado a los frameworks, ya que se puede implementar por medio de la lógica de programación en cualquier lenguaje que permita la orientación a objetos.
Esto no queda aquí ¶
Como os podíais imaginar, hablar sobre la refactorización de una aplicación legacy va a tomar más de un artículo.
Estad atentos porque pronto tendremos una segunda parte.
Mientras tanto no perdáis la oportunidad de escuchar la primera parte del episodio del podcast de web reactiva premium donde se aborda más en profundidad la refactorización de una aplicación legacy.
Escrito originalmente por: Juan José Ramos
Daniel Primo
12 recursos para developers cada domingo en tu bandeja de entrada
Además de una skill práctica bien explicada, trucos para mejorar tu futuro profesional y una pizquita de humor útil para el resto de la semana. Gratis.