Construyendo una Base de Código Sostenible con FP

Los temas principales de los que voy a hablar hoy son la programación funcional, las pruebas y la arquitectura hexagonal. Así que empecemos con la programación funcional. Sabemos que la programación funcional se trata de funciones puras, ¿verdad? Entonces, dadas sus entradas, siempre vamos a obtener la misma salida y no vamos a tener efectos secundarios. Así que cuando hablamos de efectos secundarios, podría ser como guardar en una base de datos y enviar un correo electrónico, algo así. Pero es importante tener en cuenta que también necesitaremos lidiar con funciones mejoradas porque sabemos que para tener una base de código útil, necesitamos tener funciones mejoradas. Entonces nuestros programas necesitan tener entrada y salida. Queremos poder interactuar con ellos. Y esas interacciones siempre ocurren en funciones puras. Así que después de escribir en tu base de datos, por ejemplo, vamos a cambiar su estado. Entonces, cuando vayamos a leer de la base de datos, después de guardar en ella, el resultado va a ser diferente. ¿Y cómo vamos a manejar eso? Así que necesitamos hablar sobre los efectos secundarios. Cuando estamos en la programación funcional, nos encanta hablar de las cosas puras. Pero también necesitamos hablar de los efectos. Y ese es un tema realmente importante a discutir, cómo lidiar con ellos. Así que debemos tener mucho cuidado con las funciones impuras porque cambian estados. Entonces, si ejecuto algo hoy, mañana los resultados pueden ser diferentes. Esta es la parte difícil de gestionar, pero necesitamos gestionarla. Por eso necesitamos estructurar cuidadosamente nuestra base de datos para no interferir con ella. Aquí tienes un ejemplo. Imagina que tienes una función impura dentro de una ejecución pura. Entonces ya no tienes una función pura.

Por eso necesitamos tener cuidado al estructurar nuestro código. Queremos maximizar las funciones puras que tenemos. Por lo tanto, no podemos llamar a una función impura dentro de una ejecución pura porque la hemos perdido. Así que necesitamos separar lo que construimos. Necesitamos los efectos de las funciones puras. Los efectos pueden infectar todo. Y nuestro objetivo aquí es maximizar nuestra programación funcional y minimizar y aislar las funciones impuras, el código imperativo. Por lo tanto, lo que siempre debemos tener en cuenta es que si una función podría ser pura y no lo es, lo estamos haciendo mal. Así que intentemos refactorizar esto.

Otra cosa poderosa de la programación funcional es cuando hablamos de la inmutabilidad versus la mutabilidad. Comencemos con la imagen que tenemos a la izquierda. Tenemos un libro con muchas páginas. Este libro es la identidad. Cuando quieres cambiar algo en el dibujo, simplemente pasas la página y dibujas una nueva cosa al final. Entonces, el acto de pasar las páginas representa el estado del dibujo a lo largo del tiempo. Por lo tanto, si te detienes en una página, puedes observar el estado en un cierto punto del tiempo.

Pero si miramos ahora a la derecha, tenemos un ejemplo mutable donde el libro es solo una página. Entonces, si quieres hacer un cambio, necesitamos borrar cosas y volver a dibujar. Así que aquí hemos perdido la noción del tiempo. Y el estado y la identidad ahora están mezclados. Así que cuando hablamos de inmutabilidad aquí, tenemos la animación. Conoces todos los pasos que ha dado tu dibujo para llegar al final. Conoces toda la historia.

Entonces, al hablar de funciones puras más inmutabilidad, vamos a tener funciones que son fáciles de razonar y más fáciles de depurar. Esto es lo que queremos. Porque con funciones puras, sabes que dado un valor de entrada, la salida siempre es la misma. Así que es muy fácil razonar sobre ello. Y también con la inmutabilidad, siempre tienes nuevas páginas cuando cambias algo. Por lo tanto, no necesitas profundizar en el código para entender qué función está mutando la página. Así que queremos tener en cuenta las cosas que queremos, que son funciones puras e inmutabilidad al desarrollar, para poder buscarlas. Porque esta combinación va a dar a los desarrolladores mucho poder y velocidad. Genial.

Entonces, cuando la programación es funcional, queremos enfocarnos en los datos, los cálculos, las funciones y no en las clases, interfaces y código repetitivo. Así que la intención de nuestro código es clara y puedes probar cosas nuevas más rápido. Por lo tanto, lo que queremos aquí es ser lo más funcional posible para poder avanzar más rápido y con confianza. Ahora hablemos un poco sobre las pruebas, porque si queremos una base de código sostenible, necesitamos pruebas. Las pruebas son importantes porque brindan a los desarrolladores confianza para cambiar, extender o cambiar nuestro código. Entonces, al tratar de entender, por ejemplo, un código que no escribimos, podemos verificar las pruebas para entender qué se esperaba de ese código cuando se escribió. Así que también es como documentación.

Si cambiamos el código, necesitamos cambiar las pruebas, de lo contrario se volverían obsoletas, pero no lo hacen, porque es una documentación en vivo. Pero ¿cómo sabemos y verificamos si nuestro programa está haciendo lo que se espera que haga? ¿Cómo podemos verificar la calidad de esta retroalimentación? Y aquí no voy a hablar del 100% de cobertura.

Así que empecemos con la precisión. Si tus pruebas fallan, ¿puedes determinar exactamente qué parte del código ha fallado? ¿Cuánto tiempo te lleva saber dónde falló? Así que lo que queremos aquí son funciones realmente granulares, cuanto más granulares sean, más precisión se puede obtener. Por lo tanto, es mucho más rápido si tienes funciones pequeñas sin dependencias del mundo exterior, así que recuerda las funciones puras.

También se trata de velocidad. Cuanto más rápido encontremos una prueba fallida, antes podremos identificar el problema y menor será su impacto. Así que lo que necesitamos aquí son pruebas que sean simples de escribir y mantener, y también que sean rápidas de ejecutar. Si tenemos mucho código complejo con muchas dependencias del mundo exterior, nos llevará mucho tiempo mantener estas pruebas. Y también necesitamos pruebas que sean confiables. Necesitamos confiar en el resultado de nuestras pruebas. Si el resultado cambia de una ejecución a otra, si no cambiamos el código, las configuraciones o las dependencias, ¿por qué mantener este tipo de pruebas? Porque no confiamos en ellas, así que no tiene sentido mantenerlas.

Aquí generalmente estamos hablando de pruebas de extremo a extremo. Las pruebas de extremo a extremo son un problema porque no caminas nada, realmente guardas cosas en la base de datos. Es muy común que fallen por razones oscuras, como la latencia, la recolección de basura, operaciones asíncronas. Así que necesitamos pensar de manera diferente. Aquí necesitamos pensar un poco más grande. Sabemos que las pruebas unitarias cubren los niveles de función, las pruebas de integración cubren los flujos, y necesitamos garantizar que la conversación entre los servicios funcione. Por lo general, usamos las pruebas de extremo a extremo para eso, pero podemos pensar un poco más grande y probar la conversación entre dos servicios a la vez, por ejemplo. Así que aquí usamos pruebas de contrato.

Cada prueba de contrato va a tener un servicio proveedor y un servicio consumidor, y para cada comunicación entre ellos, necesitamos definir una interfaz clara llamada contrato. Así que ahora tenemos pruebas automatizadas que aseguran que los datos generados por el proveedor pueden ser consumidos por el consumidor. Y si cambiamos algo, el contrato se romperá. Así que es importante tener en cuenta que esto no es un reemplazo uno a uno de las pruebas de extremo a extremo, pero la mayoría de los errores que las pruebas de extremo a extremo capturan, estas pruebas también pueden capturarlos. Así que con eso, podemos tener precisión, velocidad y confiabilidad. Y eso es lo que queremos.

Ahora, voy a hablar sobre cómo diseñar un registro. Porque está bien, tenemos la programación funcional, tenemos las pruebas, pero ¿cómo diseñar el código para aprovechar esto? Lo que queremos es una alta mantenibilidad con una baja deuda técnica, porque queremos que las aplicaciones que se utilizan para realizar mantenimiento tengan una baja deuda técnica. Necesitamos que sean simples y fáciles de trabajar. Y esto es difícil porque la mantenibilidad es un concepto a largo plazo porque al principio, es realmente fácil.

Tu proyecto acaba de comenzar, tenemos unas pocas líneas de código, tres personas trabajando en él. Así que solo tenemos un par de dependencias. Pero a medida que tu equipo y tu código crecen, las cosas se vuelven más difíciles. Y un error puede resultar en una refactorización completa de la arquitectura. Por eso es necesario pensar en la mantenibilidad desde el principio.

Lo que vamos a decir aquí. Entonces, el primer intento que tuvimos fue intentar utilizar una arquitectura hexagonal. Así que aquí tenemos una arquitectura hexagonal simple. El modelo de dominio donde tenemos la implementación de nuestro dominio. Aquí vamos a tener las funciones puras y los datos mutables. Por eso está en verde. Después de eso, tenemos la segunda capa donde tenemos el controlador que se encarga de conectar los puertos con los adaptadores en la lógica, el dominio. Aquí se trata de coordinación. Pero aquí ya tenemos algunas funciones que son impuras, ¿verdad? Y algunos datos mutables. Así que no son todas, pero algunas de estas son blancas, amarillas. Y en la tercera capa, aquí es donde tenemos lo que se llama IO o puertos. Y aquí interactuamos con el mundo exterior. Así que aquí vamos a hacer llamadas a otros servicios, vamos a hacer llamadas a la base de datos a APIs de terceros. Así que aquí está bien tener funciones impuras y mutación de datos, esperamos eso en la capa de IO.

Entonces, lo que queremos lograr con la segunda arquitectura hexagonal es separar la lógica de negocio de la IO. Queremos estructurar el código de manera que protejamos el dominio de las cosas técnicas. Podemos definir cuáles son las reglas de negocio, cuáles son las reglas educativas y cuál es el código de infraestructura y ¿cómo probamos esta arquitectura? Queremos probar en aislamiento con simulación porque no queremos depender de una base de datos externa o APIs externas. Realmente queremos simular y aislar las cosas para eso. Utilizamos inyección de dependencias. ¿Verdad? Estas dependencias aquí se pasan como argumentos. Así que cuando se ejecuta en producción, usamos la base de datos real y para las pruebas, por ejemplo, podemos usar un archivo codificado en duro, pero ¿cuál fue el primer descubrimiento con esta arquitectura? Así que recuerda que en la arquitectura hexagonal, tenemos nuestras funciones en los límites, ¿verdad? En la capa de IO, las que generan efectos secundarios. Así que es bueno darse cuenta de que en esta arquitectura podemos aislar y controlar los efectos secundarios en esta capa. Así que tenemos los límites aquí, como podemos ver.

Entonces hablemos de este concepto. ¿Qué significa aislamiento? El aislamiento es cuando toda la información que una función tiene del mundo exterior se pasa a través de argumentos. Así que podemos concluir que cada función par es aislada. Entonces una función par es un subconjunto de funciones aisladas. No todas las funciones aisladas son puras, pero todas las ejecuciones pares son aisladas. Y el aislamiento es el dual de la encapsulación. Entonces la encapsulación significa que el objeto tiene un estado y el mundo exterior no sabe nada al respecto a menos que se haga explícitamente disponible a través de getters y setters. Entonces el aislamiento significa que una función no sabe nada sobre el mundo externo a menos que se le ingrese. Así que es el dual, ¿verdad? Y las funciones aisladas son muy fáciles de probar y se obtienen de forma gratuita al usar programación funcional. Pero en la programación orientada a objetos, son un problema debido al principio de encapsulación. Entonces, al desarrollar con código orientado a objetos que se va a probar, necesitamos encontrar la intersección entre el aislamiento y la encapsulación. Y eso es realmente difícil porque es mucho más fácil trabajar en un subconjunto que en una intersección, ¿verdad? Así que es difícil mantener el equilibrio entre el aislamiento y la encapsulación al tratar con programación orientada a objetos. Pero con la programación funcional, no hay ningún problema en absoluto. Lo mínimo esperado de un buen diseño funcional es tener funciones puras. Y son un subconjunto de las aisladas. Así que si estás haciendo algo puro, lo estás haciendo aislado y obtienes la facilidad de la prueba de forma gratuita. Y queremos tener tantas funciones puras como sea posible para obtener todos esos beneficios, porque sabemos que si tienes funciones puras que causan una ejecución impura, también sería impura. Entonces, ¿por qué la arquitectura hexagonal en FPP es natural? Uno de los lenguajes que ayudó a entender eso es Haskell, porque Haskell es un lenguaje funcional que espera que todas las funciones sean puras. Y cuando estamos programando en Haskell, el compilador te ayuda en esa función, verificando si esa función es pura o no. Porque si escribiste una función impura y olvidaste declarar su tipo como IO, te lanzará un error. Entonces, para tener tantas funciones puras como sea posible, empujas la función impura hacia los límites. Entonces, las funciones impuras pueden llamar a la cadena de funciones puras, pero una función pura nunca puede llamar a una impura, de lo contrario obtendrás un error del compilador. Así que vamos a tener una cáscara de códigos impuros. Esto es un recordatorio de la arquitectura hexagonal. Por eso Haskell es un lenguaje que te ayuda a descubrir eso porque espera que todas las funciones sean puras. Y un buen diseño de programación funcional puede ser un deporte electrónico y adoptado. Y este es un gran descubrimiento. Pero recuerda que al principio dije que queremos aprovechar al máximo la programación funcional. Y como te mostré, todavía tenemos controladores con código imperativo y efectos secundarios.

Entonces, ¿por qué no queremos eso? Aquí voy a mostrarte un ejemplo. Imagina que tengo esta llamada funcional llamada bloquear. Y estoy pasando una tarjeta, una database y un productor. Entonces, cuando veo esta llamada funcional, no tengo idea de cuál es el resultado. Podría ser verdadero. Y si es verdadero, ¿qué significa eso? Bien, entremos en la función tratando de entender eso. Como puedes ver, tengo la tarjeta. Estoy haciendo cierta lógica en ella. Y luego llamo a la actualización en la database. Y después de eso, llamo al productor de cambios de estado de la tarjeta aquí, ¿verdad?

Entonces, aquí necesité entrar en la función para entender qué está haciendo. Y aquí no estoy devolviendo nada. Así que no tengo idea de lo que sucede antes de entrar en la función. También es más difícil componer cuando tengo código imperativo. Entonces, aquí imagina que llamo a bloquear para 10 tarjetas. Imagina que en la tercera tarjeta falla. Ahora he llamado al debate para actualizar el productor y enviar mensajes, pero solo para tres tarjetas. Así que no puedo simplemente volver a ejecutar las cosas porque duplicaría los efectos. ¿Cómo manejaría esta composición? Es difícil porque estoy haciendo las cosas sobre la marcha. Y lo que tenemos aquí no es el permiso que queremos. Tenemos un permiso que tiene más integración que pruebas unitarias porque, como puedes ver en mi controlador, tengo ese tipo de funciones que llaman al debate, que llaman al productor. Así que esto no es lo que queremos. Esas funciones no son puras. Las pruebas no son tan fáciles y la manejabilidad no será buena. Así que probemos otro enfoque para eso.

¿Qué tal si usamos la architecture hexagonal con rechazo de dependencias? ¿Qué significa eso? Que separamos el acoplamiento, las decisiones, de los hechos. Desacoplamos la intención de la ejecución. Entonces, la misma función, pero ahora cuando llamo a bloquear, solo paso la tarjeta. No paso la database ni el productor. Y como puedes ver, tengo un retorno. Y mi retorno es un objeto que tiene una clave llamada datos de hechos, y tiene su valor y una clave llamada mensaje de hechos, y tiene su valor.

Ahora sé lo que hace la función. Pero claro, puedo entrar para entender mejor. Y como puedes ver, aquí solo estoy llamando a la lógica que es una función pura, y simplemente estoy creando. ¿Qué quiero hacer? ¿Cuál es mi decisión? Y quiero actualizar la tarjeta, y tengo los data que necesito para eso. Y también quiero enviar un mensaje. Tengo los data que necesito para eso, pero no estoy haciendo nada. Esta función es pura. Por lo tanto, puedo probarla usando pruebas unitarias, por ejemplo. Es realmente fácil de razonar. Además, será fácil de componer, porque antes estábamos iterando y guardando cosas en la database y produciendo mensajes. Pero ahora, no estoy haciendo eso. Solo estoy creando un objeto. Mencionamos las 10 tarjetas. Eso va a tener un array con las 10 tarjetas. Y lo que quiero hacer es intentar hacer eso solo una vez, no durante el proceso. Eso sería más difícil de recuperar. Así que lo que tenemos aquí es que ahora tenemos operaciones atómicas, y tenemos los data como ciudadanos de primera clase. Y eso es realmente poderoso, porque como pudiste ver, vimos el data pasando, porque estamos devolviendo un objeto con lo que queríamos hacer. Antes, solo estábamos haciendo cosas, y no teníamos idea de lo que estaba sucediendo. Y cuando tienes los data como ciudadanos de primera clase, obtenemos este poder para entender mejor lo que nuestro código está haciendo. Y también, ahora nuestros controladores son puros. Solo estamos haciendo los efectos secundarios en la IO. Eso es lo que queríamos desde el principio, pero no pudimos hacerlo con la inyección de dependencias. Así que ahora solo estamos ejecutando el código InPure en la capa de IO, y tenemos los controladores puros. Por eso también está en verde. Así que eso es todo, tenemos controladores sin efectos secundarios. Y ahora somos más expresivos. Nuestro código nos cuenta mejor la historia de lo que estamos haciendo. Entonces, lo que queríamos para tener una base de código sostenible era tener tantas funciones puras como fuera posible, lo logramos. Queríamos poder tener pruebas que sean, que tengan precisión porque tenemos muchas funciones puras. Podemos tener mantenibilidad porque cuando tenemos pruebas unitarias, es mucho más fácil mantener las pruebas de integración, ¿verdad? Y también con inmutabilidad, también es más fácil entender las cosas. También es mucho más fácil debug. Con esta arquitectura, podemos obtener todas esas cosas. Eso es todo. Gracias por su atención. Aquí están nuevamente mis redes sociales y también Brisa, la empresa para la que trabajo está contratando. También puedes seguirme en Twitter, así puedo twittear este enlace. Será más fácil para ti, pero eso es todo, gracias por su atención.