Un framework propio en 2026
Empecé a programar en COBOL, en un Philips — creo que de la serie 6000; la memoria también se jubila — cuando los ordenadores personales todavía no existían. Desde entonces he hecho casi todo lo que se puede hacer en este oficio, salvo diseño gráfico, vídeo y CAD. Tengo sesenta y cuatro años y estoy a punto de jubilarme.
Antes de apagar la pantalla por última vez quiero dejar por escrito lo que a mí me ha funcionado, por si a alguien le sirve. Este blog es eso: ni marca personal, ni cursos, ni newsletter. Notas de despedida de alguien que lleva toda la vida manteniendo sistemas que no se podían caer.
Empiezo por la confesión que más extraña a la gente joven del oficio: una docena de webs en producción — directorios sectoriales, un par de buscadores con anuncios, envío de boletines, paneles de gestión internos — y todas corren sobre un framework PHP que no está en GitHub, no sale en ninguna encuesta y no lo conoce nadie. Lo escribí yo. Y es de las mejores decisiones técnicas que he tomado.
La restricción que manda
No es nostalgia. Es aritmética: soy un negocio de una persona. La restricción que gobierna todas mis decisiones técnicas no es la elegancia ni el rendimiento — es que todo esto lo tiene que poder mantener una sola cabeza durante décadas. Cada dependencia externa es un contrato con un desconocido que puede cambiar de opinión, de licencia o de vida. Cada versión mayor de un framework de moda es una migración que yo no pedí. Mi framework no me ha pedido una migración jamás: cuando cambia, es porque yo lo cambié, y sé exactamente por qué.
Cómo es por dentro (patrones, no planos)
Un directorio canónico con el framework, y cada aplicación lleva una copia idéntica
más su propio directorio de aplicación con lo suyo. El gestor de paquetes es rsync;
el lockfile es un contrato escrito: la copia del framework no se toca nunca — el arreglo
va siempre en la aplicación, y si de verdad hay que tocar el framework, se toca en el canónico y
se resincroniza con auditoría. Suena artesanal. Lo es. También significa que ninguna de mis webs
puede romperse porque otra necesitara una versión distinta de algo.
La capa de datos son cuatro funciones — leer, grabar, regrabar, borrar — con consultas preparadas y la base de datos como parámetro. Está prohibido instanciar el driver a mano en un programa. ¿ORM? El SQL a la vista envejece mejor que cualquier abstracción que lo esconda: una consulta de hace diez años se lee hoy exactamente igual.
El enrutado es un array declarado por aplicación: URL, rol que puede entrar, fichero que
responde, política de caché. «¿Qué hace esta URL?» se contesta con grep, no con
un depurador paso a paso a través de catorce capas de middleware.
Las reglas escritas
Lo que de verdad sostiene el sistema no es el código: son las reglas. Un fichero de reglas
operativas que dice cosas como: nada de operadores ternarios; todo if con llaves
aunque tenga una línea; todo formulario que modifica algo va por POST con su token; el esquema
de la base de datos vive en ficheros SQL y jamás se altera desde el código. Parecen manías de
viejo. Son decisiones tomadas una sola vez para no volver a discutirlas — ni siquiera
conmigo mismo. La consistencia es lo que hace que un fichero de hace ocho años se lea como si
lo hubiera escrito ayer.
El ritual aburrido
Desplegar es una liturgia corta y siempre igual: comprobación de sintaxis de cada fichero, copia de seguridad con fecha y motivo antes de sobrescribir nada, verificación de que lo subido es byte a byte lo que había en local, y un minuto y medio mirando el log de errores. Aburrido a propósito. El despliegue perfecto es el que no deja anécdota.
Lo que duele
No vendo humo: mantener copias idénticas exige resincronizaciones litúrgicas; no hay tipado; los tests automatizados nunca llegaron a ser lo que deberían; y algún aviso antiguo sobrevive en un rincón del log. Esto no es una receta universal — es un óptimo local para un negocio unipersonal que tiene que seguir funcionando dentro de diez años, lo actualice yo o no.
Patrones, no planos
Una nota sobre lo que no voy a contar: escribiré sobre patrones y decisiones, nunca sobre la geografía concreta de mis sistemas. Un viejo programador también sabe que la seguridad empieza por no regalar el mapa. Si algún ejemplo parece vago a propósito, es que lo es.
El giro final
Y la razón de que este blog exista ahora y no hace cinco años: el último fichaje del equipo no es humano. Una inteligencia artificial trabaja a diario dentro de este framework — y las mismas reglas aburridas que me protegían de mí mismo resultaron ser exactamente lo que un agente necesita para no romper nada. De cómo le construí a esa IA su propio sistema operativo — con MySQL, PHP y bash — trata el siguiente artículo.
— un viejo programador · 64 años · rss