Agilidad, purismo y pragmatismo

Hoy me he despertado con un email de Sensio felicitándome por los diez años que llevo formando parte de la comunidad Symfony, medidos según mi perfil en Sensio. ¡Diez años! El tiempo vuela.

Más allá de la anécdota, porque este badge sólo representa el aniversario desde que rellené un formulario para darme de alta en Sensio, diez años son mucho tiempo trabajando con Symfony. Para cuando rellené aquel formulario llevaba ya algún tiempo trabajando con las primeras versiones de Symfony, utilizándolo como framework para poner un poco de orden en los desarrollos que hacía en mi empresa. El cambio respecto a cómo solíamos trabajar antes de Symfony era espectacular, y nos permitía además una velocidad de desarrollo mucho mayor.

Symfony y composer han sido tractores de una revolución no sólo en la forma en que trabajamos, si no en el propio lenguaje y en la comunidad PHP.

Cuando empecé a trabajar con PHP, cerca de 1997, el lenguaje estaba en su versión 3. Era habitual mezclar en un único archivo PHP el acceso a la base de datos, el procesamiento de formularios, el marcado HTML, CSS, Javascript,… las “migraciones” se hacían a mano en línea de comandos o usando phpMyAdmin y el despliegue a producción consistía en copiar estos archivos mediante FTP, a menudo usando FileZilla y un creativo renombrado de archivos por si algo salía mal. La reutilización de código se hacía a golpe inclusión de  archivo, y era vital conocer la diferencia entre include y require y la increíble lista de inconsistencias y miserias de PHP. Por supuesto, las pruebas de código brillaban por su ausencia. ¿He mencionado que no existía orientación a objetos en PHP? No cabe duda de que éramos extremadamente ágiles poniendo cosas en producción, pero a costa de una calidad más que dudosa.

Han pasado más de veinte años de esto y afortunadamente para todos -empezando por los clientes- el desarrollo en PHP no tiene absolutamente nada que ver con aquello. Hemos adoptado los principios SOLID, los patrones de diseño, la integración y despliegue continuos, el desarrollo basado en pruebas, DDD, CQRS, Event Sourcing,… hasta empezamos a romper nuestros monolitos en microservicios y a empujar PHP más allá de sus límites naturales con ReactPHP o AMP. Y buena parte de todo esto empezó con Symfony y composer.

Sin embargo, toda esta complejidad añadida comienza también a generar ciertas fricciones en la comunidad de desarrolladores PHP. Por un lado, los programadores PHP más experimentados se quejan de que las nuevas generaciones saben programar con Symfony, no con PHP: si propones a un programador junior que haga una API con un único endpoint que devuelva la hora actual formateada en JSON lo más probable que empiece instalando Symfony o Laravel, en lugar de crear un simple script de menos de diez líneas que haga el trabajo que se ha pedido. Por otro lado, hemos pasado de hacer consultas a la base de datos con mysqli_query() a PDO, y de este a un ORM como Doctrine, para volver a usar consultas directas a base datos y transformación a DTO para los modelos de lectura de CQRS. Hemos pasado de la complejidad y dificultad de mantenimiento de un monolito a la complejidad y dificultad de mantenimiento distribuida de los microservicios, y de estos a buscar un punto intermedio en el monolito desacoplado. Del espaguetti code al lasagna code.

Ahora pasamos a veces demasiado tiempo discutiendo el nombre de una carpeta, si un servicio concreto pertenece a la capa de aplicación o de dominio, creando capas y más capas de abstracción e indirección que hacen más complicado tener la visión general del problema, refactorizando código antiguo, definiendo una arquitectura perfecta para un problema que -asumámoslo- no conocemos en su totalidad. Y mientras continuamos con este trabajo de arquitectura, refactor, rediseño,… el reloj de negocio sigue parado. La calidad técnica puede ser excelente (o no), pero a cambio hemos pasado semanas sin entregar valor al negocio.

¿Cuánta arquitectura es demasiada arquitectura? Quizá sea una cuestión de purismo contra pragmatismo, o simplemente de sentido común. Los valores de Scrum y su foco en la calidad, pero también en la entrega de valor temprana y la gestión del riesgo, pueden echarnos un cabo en todo esto.

Valores de scrum

Dejaré esto para un próximo artículo, pero por el momento no olvidemos que no conocemos el problema en su totalidad y por tanto podemos dar por hecho que tendremos que revisar algunas decisiones y cambiar cosas en ese planteamiento arquitectónico que tanto nos ha costado tejer. No he participado en un sólo proyecto en el que no haya habido que cambiar decisiones técnicas a medida que hemos descubierto nuevas necesidades. Y que lo más importante es ser transparentes con negocio y con nuestro propio equipo, capaces de inspeccionar nuestro trabajo y adaptarnos con el menor riesgo y el mayor valor para el negocio, en todo momento.

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.