Las dependencias de código son el diablo.

«El cambio es la única constante Her» – Heráclito (Filósofo)

Las herramientas, bibliotecas y marcos que utilizamos para crear nuestras aplicaciones web hoy en día son drásticamente diferentes de las que usamos hace unos pocos años.

Dentro de unos pocos años, la mayoría de estas tecnologías habrán cambiado drásticamente de nuevo. Sin embargo, muchos de nosotros hacemos de estos una parte central e inextricable de nuestras aplicaciones.

Importamos, usamos y heredamos los frameworks del tipo del mes como si todos fueran a estar presentes y sin cambios para siempre. Bueno not no lo son. Y eso es un problema.

Después de más de 20 años de desarrollo, diseño y arquitectura de aplicaciones web, he llegado a apreciar dos verdades importantes:

1. Las dependencias externas representan una gran amenaza para la estabilidad y viabilidad a largo plazo de cualquier aplicación.
2. Cada vez es más difícil, si no imposible, crear cualquier tipo de aplicación no trivial sin aprovechar las dependencias externas.

Este artículo trata de reconciliar estas dos verdades para que nuestras aplicaciones tengan las mayores posibilidades de supervivencia a largo plazo.

La madriguera del conejo es muy profunda.

Si empezamos a pensar en todas las cosas de las que dependen nuestras aplicaciones web, es fácil pensar en una docena o más antes de llegar al código:

• Potencia
• Conectividad
• Firewall
• DNS
• Hardware de servidor (CPU, Disco, Ram, Ram)
• Refrigeración
• Plataforma de virtualización
• Plataforma de contenedores
• Sistema operativo
• Plataforma de servidor Web
• Plataforma de servidor de aplicaciones
• Navegador web

Como desarrolladores, es bueno estar al tanto de estas cosas, pero a menudo no hay mucho que podamos hacer al respecto. Por lo tanto, ignorémoslos por ahora y hablemos solo del código.

En el código, hay tres tipos de dependencias:

1. Dependencias que controlamos

Este es un código escrito y de nuestra propiedad o de nuestra organización.

2. Dependencias que no controlamos

Este es un código escrito por un proveedor externo o una comunidad de software de código abierto.

3. Dependencias una vez eliminadas

Estas son las dependencias de código de las que dependen nuestras dependencias de código de terceros. (¡Dilo tres veces rápido!)

Vamos a hablar principalmente de dependencias que no controlamos.

Las dependencias que controlamos y las dependencias una vez eliminadas todavía pueden causar dolores de cabeza, pero en el caso de las dependencias que controlamos, deberíamos ser capaces de intervenir directamente y mitigar cualquier problema.

En el caso de dependencias una vez eliminadas, generalmente podemos confiar en un tercero para que se encargue de ellas, ya que también dependen de ellas.

Por qué las dependencias de código de terceros son buenas

Una gran parte de su aplicación web existe para resolver problemas comunes: autenticación, autorización, acceso a datos, manejo de errores, navegación, registro, cifrado, visualización de una lista de elementos, validación de entradas de formularios, etc…

Independientemente de la pila de tecnología que utilice, es muy probable que existan soluciones comunes a estos problemas y que estén disponibles como bibliotecas que puede adquirir y conectar fácilmente a su base de código. Escribir cualquiera de estas cosas completamente desde cero generalmente es una pérdida de tiempo.

Desea concentrarse en el código que resuelve un problema poco común o resuelve un problema común de una manera poco común. Eso es lo que hace que su aplicación sea valiosa: el código que implementa las reglas de negocio que son exclusivas de su aplicación, la «salsa secreta».

El algoritmo de búsqueda y clasificación de páginas de Google, el filtrado de línea de tiempo de Facebook, la sección «recomendado para ti» de Netflix y los algoritmos de compresión de datos: el código detrás de todas estas funciones es «salsa secreta».»

El código de terceros, en forma de bibliotecas, le permite implementar rápidamente esas funciones de comoditización de su aplicación, para que pueda concentrarse en su «salsa secreta».»

Por qué las dependencias de código de terceros son malas

Eche un vistazo a cualquier aplicación web no trivial creada en los últimos años y quedará absolutamente sorprendido por la cantidad de código que realmente proviene de una biblioteca de terceros. ¿Qué pasa si una o más de esas bibliotecas de terceros cambian drásticamente, desaparecen o se rompen?

Si es de código abierto, tal vez pueda arreglarlo usted mismo. Pero, ¿qué tan bien entiendes todo el código de esa biblioteca que no tienes? Una gran razón por la que usas una biblioteca en primer lugar es para obtener los beneficios del código sin tener que preocuparte por todos los detalles. Pero ahora estás atascado. Has atado completamente tu fortuna a estas dependencias que no posees ni controlas.

Quizás pienses que estoy exagerando, o hablando desde un punto de vista puramente académico. Déjeme asegurarle que tengo docenas de ejemplos de clientes que se robaron completamente a sí mismos al incrustar código de terceros demasiado estrechamente en su aplicación. He aquí un ejemplo reciente:

Un antiguo cliente mío creó su aplicación utilizando un proveedor de servicios de Backend propiedad de Facebook, llamado Parse. Utilizaron una biblioteca de cliente JavaScript proporcionada por Parse para consumir el servicio Parse. En el proceso, acoplaron estrechamente todo su código, incluido el código de la «salsa secreta», a esta biblioteca.

Tres meses después del lanzamiento inicial del producto de mi cliente, justo cuando comenzaron a obtener una buena tracción con clientes reales y de pago, Parse anunció que se cerraba.

Ahora, en lugar de centrarse en la iteración de su producto y el crecimiento de su base de clientes, mi cliente tuvo que averiguar cómo migrar a una versión de análisis de código abierto alojada por uno mismo o reemplazar el análisis por completo.

La interrupción que esto causó para una aplicación joven y en ciernes fue tan grande que mi cliente finalmente desechó la aplicación por completo.

Equilibrar lo bueno y lo malo

Hace varios años, mi solución de referencia para superar los riesgos al tiempo que conservaba los beneficios de las bibliotecas de terceros era envolverlas usando el patrón de adaptador.

Básicamente, envasa el código de terceros en una clase o módulo de adaptador que hayas escrito. Esto funciona para exponer las funciones de las bibliotecas de terceros de una manera que usted controle.

Usando este patrón, si una biblioteca o marco de terceros cambia, o desaparece, solo tiene que corregir un poco de código de adaptador. El resto de la aplicación permanece intacta.

Esto suena bien en papel. Cuando tiene dependencias autocontenidas que solo proporcionan unas pocas funciones, esto hará el truco. Pero las cosas pueden ponerse feas rápido.

¿Te imaginas tener que envolver toda la biblioteca de React (incluida JSX) antes de usar cualquiera de ellas? ¿Qué tal empaquetar jQuery, Angular o el framework Spring en Java? Esto se convierte rápidamente en una pesadilla.

En estos días recomiendo un enfoque más matizado

Para cada dependencia que desee agregar a su base de código, evalúe el nivel de riesgo que introducirá multiplicando dos factores:

1. La probabilidad de que la dependencia cambie de manera material.
2. La cantidad de daño que un cambio material en la dependencia causaría a su aplicación.

Es menos probable que una biblioteca o marco de terceros cambie cuando algunas o todas las siguientes cosas son verdaderas:

• Ha existido durante varios años y ha tenido varios lanzamientos importantes.
• es ampliamente utilizado por muchas aplicaciones comerciales.
• Cuenta con el apoyo activo de una gran organización, preferiblemente una empresa o institución de nombre familiar.

Una biblioteca o marco de terceros causará menos daño a su aplicación cuando algunas o todas las siguientes cosas sean ciertas:

• Solo se usa en una pequeña parte de la aplicación, en lugar de usarse en todo el proceso.
• El código que depende de él no es parte de esa «salsa secreta» de la que hablé antes.
• Eliminarlo requiere cambios mínimos en su base de código.
• Toda su aplicación es muy pequeña y se puede reescribir rápidamente. (Tenga cuidado con este, rara vez es cierto durante mucho tiempo.)

Cuanto más arriesgado es algo, más probable es que lo envuelvas o lo evites por completo.

Cuando se trata del código que es realmente central para la propuesta de valor de su aplicación, su «salsa secreta», debe ser extremadamente protector con ella. Haga que el código sea lo más independiente posible. Si es absolutamente necesario usar una dependencia, considere inyectarla en lugar de referenciarla directamente. Incluso entonces, ten cuidado.

A veces esto significa decir » no » a una biblioteca de terceros que crees que es realmente genial, o que realmente quieres usar por una razón u otra. Sé fuerte. Confía en mí, valdrá la pena. Pregúntale a todas aquellas personas que invirtieron mucho en la primera versión de Angular, o a mi antiguo cliente que usó Parse en todas partes. No es divertido. Créame.

Hablando de diversión, echa un vistazo a esto…

La imagen de arriba es el gráfico de dependencias para una aplicación llamada Explorador de TinyTag.

Generar un gráfico de dependencias para sus aplicaciones existentes es una excelente manera de comprender el nivel de riesgo que introducen sus dependencias. He reunido una lista de herramientas gratuitas para generar gráficos similares a los anteriores en una variedad de lenguajes, incluidos JavaScript, C#, Java, PHP y Python. Puedes conseguirlo aquí.

Ayúdame a ayudar a otros

Quiero ayudar a tantos desarrolladores como pueda compartiendo mi conocimiento y experiencia con ellos. Por favor, ayúdame haciendo clic en el botón ❤ recomendar (corazón verde) a continuación.

Finalmente, no se olvide de obtener su lista de generadores de gráficos de dependencias gratuitos aquí.