Sí, lo sé. Las últimas semanas te he pegado buena chapa con el tema de patrones de diseño, automatista.
Pero no te miento si te digo que le metí +20h. preparar esa formación en las últimas semanas. Tengo a Claude y a ChatGPT fritos iterando, afinando y peloteando ideas.
Así que cuando terminé el jueves el taller (casi tres horas y media salieron 🤯), les pasé la transcripción para que me dieran feedback.
Y ChatGPT me la devolvió en forma de bonito guantazo:
Touché, Chaty.
Este apunte se refiere a una pregunta que me hizo Marga, alumna de LVL2 en la academia, sobre cuándo usar o no sub-escenarios en Make y dónde están los límites.
Marga necesitaba un criterio que pudiera aplicar a sus automatizaciones. Y con «mi paz mental» tampoco podía hacer gran cosa.
Así que voy a intentar explicarlo mejor.
¿Qué es un subescenario en Make?
Por si estás fuera de juego: un subescenario en Make es una automatización que puede ser utilizada por otras automatizaciones.
Hay un escenario «padre» que llama a un escenario «hijo». En el escenario padre, eso se pinta como la pelotita central, con un «call a scenario»:
Y ese subescenario, tiene esta pinta:
¿Para qué usas un subescenario?
Para encargarle un trabajo concreto de manera sencilla. Le pasas unos datos, hace lo que tenga que hacer y, cuando lo necesitas, te devuelve un resultado.
Por ejemplo, lo de arriba: «Te doy la url de una imagen para que la subas a Slack y tú me devuelves el file_id de Slack listo para usar».
Dentro del subescenario puede puede haber búsquedas, comprobaciones, una tabla para traducir países y varias llamadas a una API. A quien lo utiliza le basta con conocer qué tiene que darle y qué va a recibir.
Hasta ahí, la definición. Lo interesante es lo que eso permite.
Cambiar una cosa en un único sitio.
En el taller enseñé dos automatizaciones que reciben pagos por caminos distintos, pero necesitan resolver prácticamente lo mismo: buscar o crear al cliente, preparar los productos y generar la factura.
Las dos llaman a las mismas piezas.
Si cambia la forma de buscar al cliente, actualizo esa pieza una vez. Me ahorro tener dos copias de la misma lógica y acordarme de tocar las dos.
Que hoy te acuerdas, lo sé. Dentro de ocho meses ya veremos.
(Aquí hay mucho automatista que prefiere lo de pan para hoy… y repito el escenario 3 veces si hace falta).
Entender el proceso sin abrir todas sus tripas.
Cuando vuelvo a una automatización, quiero poder leer algo parecido a:
Busca al cliente → prepara los productos → genera la factura.
Cada una de esas acciones puede llevar unos cuantos módulos por dentro. Tenerlas separadas me permite entender primero el proceso y entrar en el detalle de la parte que necesito revisar.
Eso también ayuda cuando la automatización la tiene que mantener otra persona.
Acotar lo que tengo que revisar cuando algo falla.
Si falla la generación de la factura, tengo una pieza concreta que recibe unos datos concretos y hace un trabajo concreto.
Puedo revisar qué recibió, qué hizo y dónde se atascó. Y, si está preparada para repetirse sin duplicar resultados, volver a ejecutar esa parte.
Separarla no resuelve los errores por arte de magia pero sí que me facilita (y MUCHO) trabajar con ellos.
Preparar un cambio que ya veo venir.
Uno de los subescenarios que enseñé tiene un solo módulo: enviar un mensaje por Slack. Uno. Lo tengo separado así porque lo llaman varias automatizaciones (unas 10) y porque es bastante probable que ese cliente cambie de herramienta de comunicación.
Cuando ocurra, prefiero cambiar el destino en una pieza a buscar todos los sitios donde habíamos puesto un módulo de Slack.
Ahí el tamaño del subescenario importa bastante poco. Lo que importa es dónde va a tocar hacer mantenimiento.
Todo esto tiene un precio, claro.
Más escenarios que localizar. Más historiales que revisar. Entradas y salidas que mantener claras. Más sitios entre los que moverte cuando estás investigando un fallo.
Por eso, poder separar algo en un subescenario no debería ser razón suficiente para hacerlo.
Si recibes un formulario y guardas una fila, llevártelo a tres subescenarios probablemente te añada más trabajo del que te quita.
Elige tu propia aventura
Antes de extraer una pieza, intenta terminar esta frase:
«La voy a separar porque así…».
A. …cambio esta regla una sola vez.
B. …puedo utilizarla desde varios procesos.
C. …entiendo mejor qué hace cada parte.
D. …puedo revisar y recuperar este trabajo por separado.
Si consigues concretarlo en una de estas, ya tienes una razón que puedes discutir y valorar. Si te salen 2 o más, subescenario de cabeza.
Visto así, ahora entiendo mejor de dónde sale mi «paz mental»: de tener menos sitios que tocar, menos lógica repetida y menos cosas que recordar.
La próxima vez que me salga esa respuesta, me tocará explicar también todo lo que viene detrás.
Hasta la siguiente, automatista
Santi 🫡