Lo que aprendí manteniendo un backend en Symfony

Un cliente me pasó un backend en Symfony ya construido por otro desarrollador. Esto es lo que aprendí manteniéndolo durante meses.

Casi todo mi PHP viene del mundo WordPress: hooks, functions.php, una lógica bastante directa de petición-respuesta. Así que cuando un cliente me pasó el mantenimiento de un backend en Symfony escrito por otro desarrollador que ya no seguía en el proyecto, las primeras semanas fueron más de leer que de escribir.

Lo primero que choca viniendo de WordPress

En WordPress casi cualquier cosa puede pasar en casi cualquier sitio, para bien y para mal. En Symfony no: cada pieza tiene un rol y un lugar donde vive — controladores, servicios, repositorios — y el propio framework te empuja a respetar esa separación. Al principio se siente rígido. Después de un par de meses tocando lógica de negocio real, entendí por qué: en un proyecto que va a vivir años y por las manos de varias personas, esa rigidez es la que evita que el código se convierta en un plato de espagueti.

Doctrine, el gran cambio de chip

Venir de escribir consultas SQL a mano (o del $wpdb de WordPress) a trabajar con Doctrine como ORM me costó más de lo que esperaba. No por la sintaxis — eso se aprende rápido — sino por confiar en que el ORM iba a generar la consulta correcta sin que yo la viera escrita. La primera vez que un listado tardaba cinco segundos en cargar por culpa de un problema N+1 que Doctrine estaba generando sin que yo lo notara, aprendí a mirar el profiler de Symfony antes de dar nada por rápido solo porque “funciona”.

Lo que me quedo

Los comandos de consola de Symfony son, sin exagerar, de lo mejor que he usado en cualquier framework. Poder escribir un comando propio que se integra con el resto del sistema (con sus propios argumentos, su propia ayuda automática, su propio manejo de errores) para tareas repetitivas de mantenimiento me ha ahorrado horas.

No sé si voy a arrancar un proyecto desde cero en Symfony pronto — para lo que suelo montar, sigue siendo mucho framework para el tamaño del problema. Pero mantener este backend me ha hecho mejor programador en general: pensar en capas, en responsabilidades separadas, en qué pasa cuando el proyecto lo lleva otra persona dentro de dos años. Esa parte se la llevo a cualquier lenguaje.