Conquistando la Complejidad: Refactorizando Proyectos JavaScript

¿Qué tal, todos? Mi nombre es Phil Nash y soy un ingeniero de relaciones con desarrolladores en Datastacks. Datastacks es la empresa detrás de AstroDB, que es una base de datos vectorial sin servidor que puedes usar para construir tus aplicaciones generativas de AI. Nuevamente, mi nombre es Phil Nash. Si necesitas encontrarme en cualquier lugar de internet, estaré como Phil Nash, en Twitter, Mastodon, cualquier red social que estés usando en este momento, incluso LinkedIn, ¡Dios mío! De todos modos, lo que quiero hablarles hoy es la complejidad, la complejidad en nuestro código. Así que empecemos hablando de lo que quiero decir con complejidad. Verás, nuestros trabajos son complejos. A menudo tenemos que modelar cosas de la vida real en el medio de JavaScript o TypeScript u otro tipo de lenguaje. Y el mundo en sí mismo es inherentemente complejo, y luego nosotros simplemente agregamos a eso al intentar convertirlo en código. Y el código, por lo tanto, es inherentemente complejo.

Lo que queremos evitar es agregar más complejidad a nuestras aplicaciones de la que el problema que estamos tratando de resolver demanda en sí mismo. Y en última instancia, esto significa que nuestro trabajo se convierte en gestionar la complejidad. Si podemos mantenernos al tanto de esta complejidad, entonces nuestras bases de código se mantienen sanas, fáciles de entender y fáciles de trabajar a lo largo del tiempo y de los cambios de equipo y cosas así. Así que nuestro trabajo es gestionar la complejidad. Sin embargo, el año pasado en otras conferencias, di una charla en la que investigué los cinco principales problemas en proyectos de JavaScript que podrían descubrirse mediante análisis estático, y en el número dos estaba el hecho de que la complejidad de las funciones en nuestros proyectos era demasiado alta. Y eso es un problema. Por eso quería dar esta charla, para superar eso. Y entonces realmente la pregunta es, ¿qué es demasiado alto? Necesitamos un método para medir nuestra complejidad en nuestro código. ¿Y cómo podríamos hacer eso? ¿Cómo medimos la complejidad?

Bueno, en primer lugar, permítanme, si les mostrara un fragmento de código, si les mostrara una función como esta, una suma de números primos, y les preguntara qué tan compleja es, piensen en qué responderían y qué tan útil sería eso. Obviamente hay cierta complejidad aquí. Tenemos algunos bucles. Tenemos algunas condicionales. Estamos tratando con números primos. Eso será complejo. Y luego tenemos esta otra función. Esta es una función get words. Pasamos un número y devuelve palabras como uno, un par, unos pocos, muchos o muchos. Es una gran declaración switch. ¿Qué tan compleja es esta? Bueno, ha habido formas de medir la complejidad que se han inventado a lo largo de los años. En 1976 se inventó la complejidad ciclomática. La complejidad ciclomática asigna una puntuación a una función basada en un par de cosas. Principalmente suma puntuaciones cuando una función tiene una interrupción en el flujo. Es decir, cuando hay un bucle o un condicional en su mayoría. Y así, si observamos nuestra función de suma de números primos, la complejidad ciclomática realmente asigna una puntuación de uno por ser una función. Todo comienza como uno. Así que comienza allí arriba. Y luego asignamos uno por este primer bucle for. Hay un segundo bucle for que suma uno. Hay un condicional.

Llegamos a la siguiente condicional. Por lo tanto, obtiene una puntuación de dos porque está anidada una vez. Y luego, eventualmente, salimos completamente hasta que la puntuación final sea ocho. Por lo tanto, la complejidad cognitiva de la función suma de primos es ocho, pero nuestra función obtener palabras, que creo que acordamos que es menos compleja anteriormente, ahora solo obtiene una puntuación de uno. Es una gran declaración switch. Tenemos que considerar un valor y un número de cosas que hacer con él, pero solo estamos mirando un valor en cualquier momento. Y por eso obtiene una puntuación de uno. Y creo que eso tiene más sentido para la forma en que pensamos acerca de las cosas, la forma en que entendemos code. Para mí, el modelo de esto era como una pila de cosas en tu cerebro que tienes que considerar mientras lees partes de code. Y a medida que avanzas en algo como la suma de primos, terminas agregando cosas a la pila a medida que avanzas. Y terminamos teniendo que saber y entender en todo momento que tenemos dos variables de bucle y estamos dentro de una condicional, y eso es bastante complejo. Como es obvio, puede ser peor que esto. Y luego también hay un poco de dar vueltas mientras salimos de la pila y luego agregamos cosas nuevamente. Y tenemos que seguir trabajando para saber qué está en nuestra pila cerebral, qué realmente tenemos que considerar en este punto durante la parte de comprensión del code. Y una vez que finalmente todo se despeja, vamos a respirar aliviados porque llegamos al final de la función. Pero evitar dar vueltas y construir cosas en una pila cerebral como esa es el tipo de cosas que queremos evitar. Entonces, ¿cómo conquistamos esta complejidad? Eso es lo que el resto de esta charla va a ser como vencer eso. Y el primer paso para conquistar esa complejidad es comprender dónde está la complejidad. Les he dado esta puntuación de complejidad cognitiva, pero ahora tenemos que poder aplicar eso a nuestro code. Y así, aquí hay una demostración rápida para mostrar eso. Entonces, lo que hice fue ingresar a esto es el cliente AstraDB de código abierto escrito en TypeScript para lidiar con instancias de AstraDB. Resultó que en realidad no había nada tan complejo aquí. Entonces, tuve que agregar algunas cosas. Entonces, elegí la función más compleja y luego agregué más cosas para empeorarlo. Así que, por favor, no culpen a las otras personas que escribieron esta maravillosa biblioteca. Entonces, lo que hice fue mirar la función insertar muchos. Y aquí tengo en VS code ejecutando Sonalint, que es lo que estaba usando para ver la complejidad cognitiva antes. Y esto me dice que esta función tiene una complejidad de 34 sobre los 15 permitidos. Y así, ese es el tipo de umbral en el que Sonalint se enfoca en la complejidad cognitiva. Y tiene 13 ubicaciones en las que

Y es importante destacar nuevamente, esas pruebas deben cubrir el comportamiento existente. Si estamos corrigiendo un error en un fragmento de code, pero decidimos refactorizarlo primero, entonces esas pruebas deben cubrir todo el comportamiento existente, incluso si es incorrecto. Porque si estamos cambiando la prueba y el code al mismo tiempo, entonces no podemos saber si la refactorización funcionó. Necesitamos escribir las pruebas que aseguren que el code haga lo mismo que la función hacía una vez que lo hayamos refactorizado. Y solo entonces cambiamos la prueba y cambiamos el code para corregir el error. Y luego en ese punto podemos refactorizar. Y así, para la última parte de la charla, quería repasar algunos pequeños tips que nos ayudarán a refactorizar el code frente a esta idea de complejidad y comprensibilidad. Y así, la complejidad cognitiva, obviamente, como puntaje, castiga el code anidado. Cuantas más cosas pongamos en la pila cerebral, empujemos a la pila cerebral, supongo, más complejas se vuelven las cosas. Y por lo tanto, reducir el anidamiento te ayudará a lidiar con eso y simplemente quitar algunas de esas cosas de la pila cerebral y dejarte con menos cosas que considerar mientras lees una función. Y por lo tanto, las cosas que vamos a cubrir en esto son invertir condiciones y salir temprano, colapso estructural, extraer funciones auxiliares y solo un par de pequeñas características de JavaScript que nos van a ayudar con esto también y que son un poco más modernas. Y por lo tanto, invertir condiciones y salir temprano. Esto se refiere a lo primero que te mostré en esa función de inserción múltiple en la que dije que había esta gran condición en el exterior que verifica que la longitud del array de documentos sea mayor que cero. De lo contrario, simplemente devuelve un objeto vacío, en realidad, un recuento de inserción de cero. Esta gran condición alrededor de la función que luego tiene todo lo demás dentro de ella, obviamente, aumenta ese anidamiento. Y si invertimos la condición, es decir, si la longitud del documento es cero o menor que cero, supongo, no va a suceder realmente con un array. Pero si la longitud del documento es cero, entonces podemos devolver inmediatamente nuestro objeto cero y descartar la idea de que esto es un problema. La función luego puede continuar con la seguridad de que estamos tratando con una lista de documentos y eso está bien. Invertir y salir temprano, simplemente, sí, quita cosas de la pila cerebral y significa que no tenemos que considerarlo más adelante en la función. Simplemente quítalo de la pila cerebral. Eso es lo que estoy haciendo. El colapso estructural es algo similar. Estamos tratando de reducir el número de condicionales, especialmente los condicionales anidados, si podemos juntarlos. Y así, en este caso, insert many realmente puede manejar un objeto de opciones que puede tener un array de vectores, y luego intentará combinar esos vectores y documentos. Pero si la longitud de los vectores y la longitud de los documentos no es la misma, entonces eso es un error, porque no van a ir juntos. Pero esto es como condicionales anidados aquí. Y lo que podríamos hacer es juntar ese tipo de cosa para verificar que si tenemos vectores y si los vectores no son iguales a la misma longitud que los documentos, entonces podemos lanzar un error. Y así, esto nos permite, en este caso, salir temprano a través de un error en lugar de seguir anidando y luego podemos dejar que el resto del code continúe. Comprimir ese tipo de cosas en un condicional nos permite, sí, considerar que se ha resuelto mucho más rápido y simplemente quitarlo de la pila cerebral. Extraer métodos auxiliares, creo,

Y finalmente, algunas características del lenguaje que creo que son realmente buenas para esto. Si alguna vez has lidiado con objetos anidados y has tenido que buscar una propiedad en un objeto que está profundamente anidado, probablemente hayas escrito una de estas cadenas de object.first y object.first.second para evitar golpear un indefinido accidentalmente en algún lugar intermedio. Y un operador de encadenamiento opcional es muy útil para eso. Simplifica toda la línea de code y elimina todas esas condiciones booleanas. Realmente útil. Y en segundo lugar, si estás tratando con, digamos, en este caso estamos tratando de asignar a chunk size algo que está en options.chunk size o un valor predeterminado en este caso. Y así estamos comprobando que options.chunk size no sea nulo o indefinido. Y si es alguno de esos dos, obtenemos el valor predeterminado. Y si no, podemos asignarlo a la cosa. Y eso es un lío completo de operadores condicionales y ternarios cuando realmente podríamos usar el operador de fusión de conocimiento que es efectivamente lo mismo que decir no nulo y no indefinido. Y la línea superior aquí establecerá chunk size en el valor predeterminado solo si options.chunk size es nulo o indefinido. Y si lo estuviéramos haciendo dentro del objeto en sí, es aún más fácil con el operador de asignación nula que dice que solo asignaremos esto a un valor predeterminado si chunk size en el objeto original es nulo o indefinido. Muy útil. Aprieta las piezas de code en esos momentos y en este contexto. Y simplemente te ayuda a sacarlo de la pila cerebral. Entonces, para resumir, echamos un vistazo a qué es la complejidad. Básicamente nuestro trabajo es básicamente code. Analizamos la complejidad cognitiva como una forma de medir la complejidad. Y luego analizamos cómo conquistar la complejidad reduciendo el anidamiento, refactorizando primero, asegurándonos de tener cobertura de pruebas, refactorizando y luego realizando el cambio que necesitamos hacer. Hay algunas herramientas que te ayudarán con esto. Entonces, Sona cloud o Sona Cube pueden escanear tu code como parte de tu canalización de CI/CD y detectar problemas como este de complejidad cognitiva. Lo mismo ocurre con Sona Lint. Es gratis instalarlo en tu IDE y mostrará cosas como lo estaba demostrando antes. Y si estás usando ESLint, que no tiene la complejidad cognitiva como puntaje. Pero puedes instalar el complemento de ESLint, Sona JS, que sí lo tiene, y lo agregará a tu ESLint también. Realmente útil. Y eso es todo lo que tengo tiempo para aquí. Nuevamente, mi nombre es Phil Nash. Soy un ingeniero de relaciones con desarrolladores en Datastacks. Y muchas gracias por su atención.