Antes de empezar, un apunte rápido. A partir de ahora, los episodios de este podcast también están disponibles en vídeo, en YouTube. Así que si prefieres verlos a solo escucharlos, ya sabes dónde. Y ahora sí, vamos al lío.

Si has intentado usar mi plugin de Jitsi para Moodle últimamente y has pensado "oye, esto lleva un tiempo parado, sin novedades"… tienes razón. Y es a propósito.

Hoy quiero contarte por qué, a veces, lo más inteligente que puedes hacer con tu código no es añadirle una función nueva y brillante, sino lo contrario: pararte, mirar hacia atrás, y empezar a pagar deudas. Deuda técnica. Y por qué he decidido pagarla ahora, y no más adelante. Por el camino te voy a contar tres o cuatro cosas que me han pasado y que me han enseñado más que cualquier tutorial.

Vamos por partes.

Primero, qué es la deuda técnica, por si no te suena. Imagina que construyes una casa con prisa. Para llegar a tiempo dejas cables sueltos por las paredes, una tubería provisional, un interruptor que no sabes muy bien qué enciende. La casa funciona, se puede vivir en ella… pero cada año que pasa, esos atajos te pasan factura. Eso es la deuda técnica: las decisiones rápidas de ayer que hoy te cuestan tiempo, errores y miedo a tocar nada. Y ojo con esa palabra: miedo. Porque el síntoma más claro de la deuda técnica no es que el código sea feo; es que llega un punto en que te da pánico abrir ciertos archivos.

A mí me pasaba con dos. Dos monstruos de miles de líneas cada uno que habían crecido sin control durante años. Uno tenía casi tres mil líneas y hacía de todo: hablaba con la base de datos, con YouTube, con Google, mandaba notificaciones… un cajón de sastre. El otro guardaba, en un solo sitio, las más de cuarenta operaciones que el plugin expone hacia fuera. Añadir cualquier cosa nueva significaba bucear en uno de esos monstruos y rezar para no romper otra cosa sin querer. Lo irónico es que el resto del plugin ya estaba modernizado. Solo esos dos seguían anclados en cómo se programaba en Moodle hace diez años.

Y aquí viene el porqué del "ahora". Porque, sinceramente, podría haber seguido ignorándolos, como llevaba años haciendo. Pero es que Moodle está a punto de cambiar por dentro. De verdad. No un retoque: un cambio de cimientos.

Te lo resumo, porque es la clave de todo. Hace unos meses salió Moodle cinco punto dos, y con ella dos cambios de fondo enormes. El primero: React entra en el corazón de Moodle. React es la tecnología con la que está construida media internet, Instagram por ejemplo, para hacer interfaces modernas y rápidas. Hasta ahora, Moodle montaba sus pantallas con un sistema mucho más antiguo y artesanal. A partir de ahora, el camino es React. El segundo cambio, más técnico pero igual de importante: Moodle está jubilando su viejo sistema de "enganches" para plugins, lo que en jerga llamamos callbacks, y lo está sustituyendo por una arquitectura nueva y más limpia, los hooks. ¿Y qué pasa con los plugins que no se adapten? Que el propio Moodle los va dejando fuera, poco a poco, de la conversación. Y esto no es una idea suelta: está en la hoja de ruta oficial. Dos mil veintiséis es el año de React y de modernizar las tripas; dos mil veintisiete, el de la nueva interfaz y de más cambios todavía.

¿Ves por dónde voy? Los dos sitios donde Moodle está modernizando sus cimientos son exactamente los dos sitios donde yo tenía la porquería acumulada. Uno de mis archivos-monstruo estaba lleno de esos callbacks antiguos que Moodle va a jubilar. Y la peor pieza de todas, una función de casi mil líneas que dibuja la videollamada a mano, instrucción a instrucción, es justo el tipo de código que React viene a sustituir.

Así que la pregunta dejó de ser "¿me apetece limpiar?" y pasó a ser otra muy distinta: "¿quiero llegar a este cambio preparado, o llegar a remolque, corriendo, cuando ya sea tarde?". Y lo tengo claro: prefiero llegar preparado. Porque pagar deuda técnica, muchas veces, no va de ordenar el pasado. Va de leer hacia dónde se mueve la plataforma y no quedarte en el lado equivocado de la historia.

Ahora bien, cuando te metes en un trabajo así, pasan cosas. Y aquí van las que me han enseñado de verdad.

La primera: los tests no se escriben para encontrar bugs… pero los encuentran. Mi método fue lento y aburrido a propósito: antes de mover cada trozo de código, le escribía una prueba automática, una red de seguridad. Pues bien, escribiendo la prueba de una función ridícula, un simple botón que enciende y apaga la cámara, la prueba falló. Había un error escondido ahí dentro, quién sabe desde cuándo, que en producción no llegaba a explotar de puro milagro. Y como ese, seis o siete más. No los buscaba: aparecieron solos. La moraleja es un poco incómoda: si escribir una prueba trivial te destapa un error, no es que la prueba sea muy lista… es que tu código tenía más fantasmas de los que tú creías.

Y entre esos fantasmas, encontré una mina. Una función muerta, que ya no llamaba nadie, abandonada en un rincón. Pero si por accidente se hubiera llegado a ejecutar alguna vez, ¿sabes qué hacía? Renombraba la actividad entera del profesor a, literalmente, la palabra "modificado". Imagínate: un profesor monta su videollamada, le pone un nombre con cariño… y un día aparece llamada "modificado", sin más. Llevaba años ahí, desactivada de pura suerte. Borrar código muerto no es estética: a veces es desactivar una bomba que ni sabías que tenías enterrada en el jardín.

La segunda lección: antes de tocar lo sagrado, blíndalo. Hay una pieza en el plugin que es intocable: la que genera la llave de seguridad que da acceso a cada videollamada, el token. Si eso falla, o se rompe, o alguien consigue falsificarlo, se acabó la fiesta. Pues bien, esa pieza tan crítica… no tenía ni una sola prueba que la vigilara. Cero. Así que antes de atreverme a mover nada de ahí, lo primero que hice fue rodearla de tests, recalculando a mano su firma de seguridad para asegurarme de que seguía siendo infalsificable. Porque hay cosas que, antes de tocarlas, tienes que blindar. Refactorizar sin red, en lo crítico, no es valentía: es temeridad.

La tercera: no te fíes ni de tus propios atajos. En mitad del proceso quise comprobar que no me dejaba ningún cabo suelto, y escribí un comando "inteligente" para buscarlos. Tan inteligente que se saltó justo el único cabo suelto que tenía que encontrar. Lo descubrí de chiripa, abriendo la página en el navegador y viéndola reventar delante de mis narices. La lección me costó un susto sano: las herramientas que crees que te están ayudando a verificar… a veces son las que te esconden el problema. Desconfía un poco de tu propia astucia.

Y la última, la que más me ha hecho pensar: mover no es mejorar. Esa función monstruosa de casi mil líneas, ¿sabes qué hice con ella? La moví tal cual a otro sitio, sin arreglarla por dentro. Y soy honesto conmigo mismo: sacar un problema de un cajón y meterlo en otro reduce el desorden, pero no resuelve el problema. Es deuda cambiada de sitio, no saldada. La reescritura de verdad la he dejado para más adelante. Y fíjate qué cosa tan reveladora: la dejé pensando en reescribirla con la tecnología de "ayer"… cuando lo que viene es React. O sea que hasta mi plan de futuro tengo que repensarlo. La plataforma se mueve, y o te mueves con ella, o te quedas.

Y déjame cerrar con una reflexión, porque creo que esto va más allá del código. En el desarrollo, como en casi todo, hay dos tipos de trabajo: el que se ve y el que no. Sacar una función nueva, vistosa, que la gente prueba y comenta: eso se ve, eso te lo aplauden. Pero pasarte semanas recolocando cañerías que nadie va a mirar jamás, para que dentro de dos años tu proyecto siga encajando con una plataforma que habrá cambiado entera: eso no lo ve nadie. Hice un episodio hace un tiempo sobre que la documentación es parte del producto, aunque no se vea. Pues esto es lo mismo: la salud del código es parte del producto. El usuario no la ve directamente, pero la nota muchísimo el día que algo deja de funcionar.

Así que sí: llevo un tiempo sin sacar novedades en el plugin. Pero no porque lo haya abandonado, sino justo al revés: porque estoy haciendo el trabajo invisible, el que nadie aplaude, pero que decide si esto sigue vivo dentro de tres años o se queda en una versión que ya no encaja con nada.

Si te llevas una sola idea de todo esto, que sea esta: mover no es mejorar… pero prepararte sí es avanzar. A veces la decisión más valiente con tu código, o con cualquier cosa en la vida, no es añadir algo nuevo y llamativo, sino pararte a dejarlo listo para lo que viene. Aunque desde fuera parezca que no estás haciendo nada.

Nos escuchamos en el próximo. Cuídate.