Durante años, una parte de mi código hizo algo de lo que no me enorgullezco. En lugar de devolver datos, fabricaba páginas web enteras. Botones, menús, JavaScript… todo escrito a mano, como una larguísima cadena de texto, y desde el servidor.

Bienvenido a un nuevo episodio del podcast de Sergio. Hoy va de una idea pequeña que lo cambia todo. Cabe en tres palabras: datos, no comportamiento.

Te pongo en situación. Tengo un plugin para Moodle, la plataforma educativa, que añade videollamadas. Lo escribí hace años, y funcionaba. Pero por dentro arrastraba un vicio muy de su época.

El backend, la parte del servidor, no se limitaba a calcular cosas. Se dedicaba a escribir la página entera. Una sola función podía tener novecientas líneas. Y la mayoría no eran lógica: eran texto. El aspecto de la pantalla y cientos de líneas de JavaScript, cosidas una a una, a mano.

Abrir ese archivo daba un poco de vértigo. Porque cuando mezclas tres cosas en el mismo sitio (qué datos mostrar, cómo se ven y qué hacen) no puedes tocar nada sin miedo. No lo puedes probar de forma automática. No le puedes pasar un revisor que detecte errores. Y cada cambio pequeño se convierte en una partida a los nervios.

Así que me senté a desmontarlo. No a añadir nada nuevo. A separar.

El cambio de mentalidad de todo el refactor cabe en una frase. El servidor debe entregar datos, no comportamiento.

Te lo explico con una imagen. Imagina un arquitecto que, además de hacer los planos, baja a poner los ladrillos y a pintar las paredes él mismo. Puede funcionar. Pero el día que quieras cambiar el color de una pared, tienes que llamar al arquitecto. Lo sano es que cada oficio haga lo suyo.

En el código pasa exactamente igual. Cogí esa función gigante y la partí en tres capas. Por un lado, los datos: funciones que solo calculan qué hay que mostrar. Por otro, la presentación: el aspecto de la pantalla, en plantillas, fuera del servidor. La regla que me marqué fue muy simple: el servidor decide, la plantilla pinta. No piensa, solo pinta. Y por otro lado, el comportamiento: el JavaScript, en módulos de verdad, con su revisor de estilo.

Un ejemplo concreto. Antes, el botón para grabar una clase se imprimía como texto desde el servidor. El servidor escribía, letra a letra, el JavaScript que hacía funcionar ese botón. Con las comillas escapadas, los datos pegados en mitad del código… un horror.

Después, ese botón vive en su propio módulo. Y el servidor solo le pasa un par de datos: el identificador de la sala, el del usuario. Nada más. Dejó de fabricar comportamiento. Ahora entrega datos, y el módulo se encarga del resto.

Y lo mismo con la tabla de grabaciones. Antes, borrar una grabación recargaba la página entera y te mandaba al principio del todo. Ahora se pide solo el dato que ha cambiado y se refresca un trocito, sin que la página se mueva.

Y un detalle pequeño que me gustó cuidar, aunque casi no se note. Que al borrar una fila, la página no diera ningún salto. Que te quedes exactamente donde estabas. Eso, que parece una tontería, es lo que separa algo que funciona de algo que se siente bien.

Y aquí viene lo que no me esperaba. Cuando separas las cosas, los problemas que estaban escondidos salen a la luz.

Te cuento el mejor. Había un contador, los minutos totales de un usuario, que tenía puesto un pequeño caché. Me pregunté: ¿por qué cachear algo tan simple? Tiré del hilo. Y debajo había una consulta que, para contar unos pocos minutos, recorría la tabla de registros de todo el sistema. Entera. Millones de filas en un servidor grande.

El caché no resolvía el problema. Lo tapaba. Y esa es la pista de oro: un caché casi siempre esconde una consulta cara.

Cuando todo está amontonado, esas cosas no se ven. Al separarlo, saltan solas. Con un cambio mínimo, esa consulta pasó a ser veintiuna veces más rápida. Y el caché que la tapaba… ya ni hacía falta.

Hubo más sorpresas. Código que llevaba años sin ejecutarse ni una sola vez. Un trozo que parecía repetido, calcado a otro… pero que, si lo hubiera unificado, abría un agujero de seguridad. A veces lo que parece duplicado está separado a propósito.

Y encontré una cápsula del tiempo. Un parámetro que mi código todavía lee… pero que no genera ningún archivo del plugin. ¿Quién lo manda? La aplicación móvil de Moodle. Lo metió un compañero hace años, en un commit titulado, literalmente, "compatibilidad con la versión cinco". Decidí no tocarlo. Romperlo significaría romper a los usuarios de la app. Refactorizar código viejo es un poco de arqueología: lees mensajes de gente del pasado, a veces de ti mismo, y aprendes a leerlos con respeto antes de borrar.

Vale. Llegados aquí te preguntarás: ¿y todo esto para qué? No he añadido ni una sola función nueva. La videollamada hace exactamente lo mismo que antes.

Y esa es, justamente, la cuestión. Este tipo de trabajo no se ve por fuera. Pero hace posible lo que viene.

Moodle está cambiando sus tripas. Va hacia interfaces reactivas, el estilo de las aplicaciones modernas, lo que en el mundo del desarrollo se conoce por una librería llamada React. ¿Y qué necesita una interfaz reactiva para funcionar? Exactamente esto. Que el servidor entregue datos. Y que el aspecto y el comportamiento vivan en el frente, consumiéndolos.

Si tu servidor se dedica a fabricar páginas como cadenas de texto, no tienes nada que enchufar a ese mundo nuevo. Te quedas fuera. Así que separar datos, presentación y comportamiento no es limpieza por gusto. Es construir el cimiento sobre el que se levantará lo siguiente.

Y me llevo una idea que va mucho más allá de este plugin. Sirve para casi cualquier sistema que construyas. Separa el qué (los datos) del cómo se ve, y del qué hace. No mezcles a quien calcula con quien pinta. Porque el día que quieras cambiar una de las tres cosas, lo vas a agradecer.

Datos, no comportamiento. Una frase pequeña. Detrás hay semanas de trabajo que nadie va a ver… y un plugin, por fin, preparado para lo que viene.

Gracias por escuchar el podcast de Sergio. Nos escuchamos en el próximo.