Construyo plataformas educativas desde la interfaz hasta los datos y la operación.
Construyo aplicaciones, servicios, procesos e integraciones desde la interfaz hasta los datos y la operación. Esa práctica me permite decidir la arquitectura conociendo sus consecuencias en cada una de esas capas.
Criterio profesional
Trabajar de un extremo al otro da una ventaja: se ve el efecto de cada decisión en el lado contrario. También da la tentación de saltarse los límites, y ahí es donde hay que tener disciplina.
Cuando el mismo desarrollador hace la interfaz y el servicio, es fácil colar lógica de negocio en la pantalla porque va más rápido. Va más rápido hoy y lo paga el siguiente que necesite esa regla en otro sitio.
La interfaz y el servicio pueden sustituirse sin migrar todo el histórico, aunque el esfuerzo depende de su alcance y de los contratos existentes. Cambiar el modelo de datos suele exigir migraciones, compatibilidad, reconciliación y validación sobre información acumulada; por eso acostumbra a ser la decisión menos reversible. El plazo solo puede estimarse después de medir esos factores.
Pruebo también la interfaz: los recorridos, los permisos y los estados de carga, vacío y error. Una revisión visual puntual no detecta por sí sola las regresiones que puede introducir el siguiente cambio.
La tecnología más adecuada sobre el papel es la peor decisión si el equipo que se queda no la conoce y no hay presupuesto para que la aprenda.
Dónde se concentra la complejidad
Se gestiona entre correos y hojas de cálculo, o entre dos aplicaciones que no se hablan, o dentro de algo heredado que ya nadie toca. Funciona hasta que crece el volumen o se marcha quien lo llevaba.
Un proceso se gestiona a mano entre correos y ficheros compartidos porque ningún sistema lo cubre. Funciona hasta que crece el volumen o se va la persona que lo llevaba.
Cada uno guarda una parte de la verdad y no se ha definido cuál manda sobre cada dato. Las discrepancias aparecen en el peor momento.
La información existe pero vive dentro de una aplicación que no la deja salir de forma consultable, así que nadie puede analizarla.
No hay equipo para separar frontal, servicio, datos y despliegue, y hace falta alguien que responda del conjunto sin dejar huecos entre capas.
Funciona, pero cualquier cambio rompe otra cosa. Hay que decidir si se estabiliza, se reescribe por partes o se sustituye.
Lo que se hizo para demostrar una idea ahora debe funcionar en producción, con seguridad, errores controlados y alguien que lo opere.
Qué miro y qué queda por escrito
Cuando la necesidad no cabe dentro del LMS, o no debe estar dentro, esto es lo que se acaba construyendo.
Herramientas internas para procesos que ningún producto cubre: seguimiento, coordinación, revisión, aprobación. Con sus roles, sus estados y su registro de quién hizo qué.
Servicios con contrato explícito, versión declarada y comportamiento definido cuando el otro extremo falla o tarda. Con autenticación y límites de uso donde hacen falta.
Lo que debe ocurrir sin que nadie lo lance: sincronizaciones, cálculos, envíos, cierres. Con estado visible, reintentos y capacidad para reanudar la ejecución desde el punto en que se interrumpió.
Estructuras pensadas para preguntar, no solo para guardar, con extracciones periódicas hacia donde se analiza y trazabilidad hasta el registro de origen.
Pantallas que usa gente que no eligió usarlas, así que tienen que ser rápidas, entendibles y accesibles. Con los estados de carga, error y vacío resueltos, que es donde se nota el oficio.
Entender qué hace algo que ya nadie toca, cubrirlo con pruebas antes de cambiarlo y sustituirlo por partes sin parar el servicio que presta.
Responsabilidades concretas
La interfaz, el servicio, el modelo de datos y el despliegue. Los fallos más difíciles de resolver no viven dentro de una capa: viven en el espacio que queda entre dos, donde nadie se siente responsable.
Qué hace el frontal, qué el servicio, qué la base de datos y qué queda fuera. Los fallos cuya responsabilidad queda sin asignar se cuelan en los huecos entre capas.
Interfaz utilizable y accesible por delante, servicios y procesos por detrás, con la misma exigencia de calidad en ambas capas, algo que no siempre ocurre.
Pensar el modelo desde el principio para que alguien pueda hacerle preguntas después, en lugar de descubrir a los dos años que la información está pero no se puede extraer.
Qué se expone, con qué versión, qué ocurre cuando el otro extremo no responde y quién se entera. Una integración sin contrato es una avería aplazada.
Despliegue repetible, errores que se ven, capacidad de volver atrás y suficiente información para diagnosticar sin adivinar.
Documentación, pruebas y decisiones explicadas para que el equipo que se queda pueda seguir sin depender de quien lo escribió.
Cómo trabajo
Empiezo por lo que más riesgo tiene, porque dejar lo incierto para el final es la manera habitual de descubrir tarde que el diseño no servía.
Lo que se pide suele ser una solución ya imaginada. Vuelvo al problema antes de aceptar la forma en que llega.
Qué hace cada capa, qué guarda cada sistema y por dónde se hablan. Antes de escribir código.
Primero lo que puede invalidar el diseño. Dejar lo incierto para el final es la forma habitual de descubrir tarde que no funcionaba.
Las reglas de negocio y los recorridos completos, no solo las funciones fáciles de probar. Y comprobar que las pruebas fallan cuando deben.
El trabajo no termina con la entrega, sino cuando el sistema funciona con personas que lo usan y el equipo puede operarlo sin mí.
Recorrido profesional
Blog
Sobre cuándo conviene una aplicación propia y cuándo no, cómo se define un contrato entre sistemas que aguante el cambio, y qué hacer con el código heredado que funciona pero que nadie se atreve a tocar.
Contacto
Las hojas de cálculo y los correos suelen conservar reglas, excepciones y responsabilidades que hay que entender antes de convertirlas en software.