WRP 18. Refactorizar una aplicación legacy (Parte 1)

Ponemos a prueba un script que promete hacernos la vida más fácil para crear aplicaciones web.

Muchas gracias a todos los que habéis asistido al directo, en muy poco tiempo estará disponible en la Zona Premium. Estoy buscándole un nombre a estas sesiones y pronto llegará el “live coding”.

Las secciones Noticias noticiosas y Un paseo por Github solo están disponibles si eres suscriptor.

Primeros pasos de la refactorización

Planteamos hoy una primera parte de una miniserie de episodios dedicados a refactorizar una aplicación “imaginaria” de alto valor para una empresa, pero a la que nadie quiere hincar el diente por la dificultad que arrastra ahcer cualquier modificación.

Nos basamos en la historia montada en los últimos capítulos de Pro PHP Refactoring. Un libro antiguo que he redescubierto hace poco y que creo contiene las bases para gestionar la programación de nuestras aplicaciones con buenas prácticas.

Eso si, matizaremos varios aspectos a lo largo de nuestro recorrido, actualizando lo que cuenta el manual para aprovechar las nuevas librerías.

Nuestro caso de uso es algo como esto

Tenemos una aplicación para gestionar un listado de productos. Los productos se crean, se editan y se borran. Toda la empresa depende de este sistema porque gestiona dos cosas esenciales: la disponibilidad del producto y el precio

No son productos complejos, con muchos atributos. Hay más de 100 mil productos.

PHP 5, MySQL y Apache

Nos piden incluir modificaciones en la forma de establecer los precios de los productos.

¿Quién se atreve? Nadie, todos los valientes echaron a correr :)

Gran bola de lodo

La aplicación es una gran bola de lodo, una Big ball of Mud. Código que mezcla llamadas a la base de datos, generación de plantillas y control de accesos sin ningún rigor ni “separación de intereses”.

Nuestro destino es tener una aplicación que siga la arquitectura “Modelo-Vista-Controlador” (gráfico). Hay mejores opciones en la actualidad, pero conseguir tener esa estructura sería un logro.

La importancia del testing

Ya hablamos de él en el episodio 59. En nuestro caso necesitamos crear tests de regresión funcionales. Esto es, probar, como si fuéramos un usuario que entra en el navegador, a ejecutar las acciones básicas del sistema: crear, editar, borrar y leer los productos. Pero todo esto de forma automática.

Aquí tenemos una lista de recursos que nos puede ayudar:

[Solo disponible si eres suscriptor]

Un camino largo pero muy provechoso

Acabamos el episodio con el sistema instalado en local y entendiendo un mejor la colección de recursos que debemos conocer antes de emprender este viaje:

• Control de versiones Git
• Instalación en local del entorno con Docker, MAMP, WAMP…
• Ejecución de tests funcionales (o de aceptación)
• Mucha ilusión :)