Estructura y organización
Aunque la construcción de la lógica se realiza a través de un editor visual, requiere seguir criterios estructurados para garantizar la claridad y la mantenibilidad. Esta sección propone una estructura básica y esboza las mejores prácticas que favorecen un desarrollo coherente en todos los proyectos y equipos, reduciendo la probabilidad de errores y facilitando el trabajo colaborativo.
Como no toda lógica requiere el mismo nivel de estructuración, es importante adaptar el enfoque en función de su volumen y complejidad. Para procesos sencillos y limitados, puede bastar con un flujo lineal sin variables ni funciones auxiliares. Esto es habitual en la lógica destinada a modificar el comportamiento de los componentes de la pantalla (lógica de presentación). Para procesos medios o complejos, es necesario organizar la lógica en funciones específicas y evitar estructuras difíciles de leer con anidamiento profundo. Las buenas prácticas que se detallan a continuación están orientadas principalmente a este tipo de procesos.
Simplicidad: Para procesos sencillos y de bajo volumen, mantén la lógica lineal y concentrada dentro de la declaración principal. Evita la sobreingeniería.
Modularidad basada en la complejidad: A medida que la lógica crece e incorpora decisiones, validaciones o ramas, debes estructurarla mediante funciones.
Reutilización: Extrae validaciones o cálculos repetidos en funciones para reutilizarlos en cualquier otra parte del proceso.
Uso de variables para el tratamiento interno de datos: Evita los tokens innecesarios. Los tokens sirven principalmente para intercambiar información con otras entidades, transacciones o call APIs. Para el procesamiento interno, utiliza variables lambda.
Prevención de efectos secundarios inesperados: Asegúrate de que las funciones no provoquen efectos secundarios inesperados. Esto ocurre cuando una función modifica implícitamente datos globales o externos de un modo que no resulta evidente en su definición.
Organizar el proceso en secciones claras ayuda a garantizar su comprensión y mantenimiento. La siguiente estructura sirve de guía general y puede adaptarse en función de la complejidad del proceso. Puede incluir o no todos los componentes enumerados a continuación, pero seguir este orden favorece la coherencia entre proyectos. La siguiente estructura encapsula las diferentes partes de la lógica en funciones específicas:
Inicialización de variables y estructuras: Prepara las variables necesarias para el proceso. Si el proceso recibe información a través de tokens de entrada, asignarlos a variables locales en esta etapa. Nombre de la función: initVariables()
Validaciones y transformaciones iniciales: Comprueba las condiciones previas, valida los datos de entrada y realiza transformaciones o cálculos iniciales. Nombre de la función: validateInput()
Invocaciones externas (transacciones y call APIs): Encapsula cada llamado externo en una función independiente que incluya su propio tratamiento de errores. Esto mejora la legibilidad del flujo principal, reduce el ruido visual de grandes bloques, como los de transacciones, y facilita la comprobación de partes específicas del proceso.
Definición de tokens de respuesta y salida: Al final del proceso, prepara los datos de salida y asígnalos a las tokens de salida, si aplica. Nombre de la función: setResponse()
El bloque on start debe incluir la lógica principal del proceso, es decir, la lógica que representa el propósito principal del proceso, y realizar las llamadas a las funciones descritas anteriormente. Esta estructura admite una ejecución secuencial clara y permite que el bloque on start actúe como orquestador de funciones auxiliares, manteniendo la lógica visual organizada y predecible.
Aunque estructurar la lógica en funciones es una buena práctica, un uso excesivo puede ser contraproducente. Por un lado, desglosar innecesariamente la lógica puede dificultar la comprensión global. Por otro lado, es mejor evitar las cadenas de funciones sin sentido -como un bloque on start que simplemente llama a una función, que a su vez llama a otra, y así sucesivamente. Estas estructuras no añaden ningún valor real y hacen que el flujo principal sea más difícil de seguir. Lograr un equilibrio entre claridad y modularidad es clave para construir una lógica que sea fácil de mantener y de entender.
Actualmente, los procesos lambda no tienen un límite de tamaño estricto, pero deben seguirse las siguientes normas para garantizar la claridad y la mantenibilidad:
Evita los procesos excesivamente largos (más de 250 bloques), ya que se vuelven difíciles de seguir y propensos a errores.
En procesos complejos, divide la lógica en subprocesos para mejorar la mantenibilidad.
Evita fragmentar demasiado la lógica en funciones sin una razón clara. Tener más de 10 funciones en una lógica medianamente compleja puede ser un signo de exceso de ingeniería.
Los procesos lambda no reciben parámetros explícitos; en su lugar, comparten información con otras entidades a través de tokens. Utilizar la estructura del modelo presentada anteriormente debería permitirte definir claramente los datos de entrada y de salida. En caso contrario, es aconsejable utilizar comentarios para documentar explícitamente qué tokens espera y modifica el proceso.