Actualmente, el uso de librerías en proyectos web está muy extendido. Si nos centramos en el ecosistema de Nodejs, concretamente en el gestor de paquetes NPM, tenemos más de medio millón de librerías a nuestra disposición. ¿Increíble, verdad?
Diariamente encontramos problemas o retos en nuestras aplicaciones que solventamos gracias al uso de librerías o paquetes externos. Sin embargo, ¿nos compensa siempre su uso? Con un sólo comando somos capaces de instalar una nueva librería. No obstante, ¿qué repercusiones puede tener esto a largo plazo? Una librería puede no ser la mejor solución y lejos de resolver un problema, a veces nos puede traer muchos dolores de cabeza: debemos de tener en cuenta que el código ya no está en nuestro repositorio y que perdemos el control sobre este.
En este artículo vamos a abordar cómo realizar una gestión responsable de dependencias en nuestros proyectos. En la sección "Evalúa tu librería", encontrarás 5 preguntas que te ayudarán a evaluar una librería y equilibrar los riesgos que asumimos con las ventajas que nos proporcionan.
Primer paso: analiza tu proyecto
Antes de centrarnos en cómo analizar una librería, debemos pararnos a analizar nuestro proyecto. En primer lugar hay que tener en cuenta el marco en el que desarrollamos el proyecto. No es lo mismo plantear qué librería incluir en un proyecto que se enmarca dentro del ecosistema de una empresa, que hacerlo para un proyecto personal. Los riesgos que podemos asumir y el ciclo de vida de los proyectos son completamente diferentes. El nivel de exigencia a la hora de elegir una librería varía en función de la tolerancia del proyecto a los fallos y el ciclo de vida de este.
El nivel de exigencia a la hora de elegir una librería varía en función de la tolerancia del proyecto a los fallos y el ciclo de vida de este.
¿Quién no ha tenido que trabajar con una librería que ya no existe? El ciclo de vida de un proyecto puede extenderse incluso durante años, por lo que nos tocará mantener aquellas "decisiones" que tomamos en el pasado.
Otro aspecto a tener en cuenta es el ámbito de la librería. La decisión de qué framework de Frontend utilizar, ya sea React, Angular o Vue no tiene la misma importancia que elegir la librería que gestiona un dropdown. Dicho de otra manera, es más importante decidir los cimientos que el tipo de puerta de una casa.
Cuando elegimos un framework base estamos condicionando todo nuestro código, y tendremos que seguir con dicha carga durante todo el ciclo de vida. Pivotar de un framework a otro no es sencillo y requiere mucho trabajo. Por ello, debemos ser extremadamente exigentes a la hora de tomar esta decisión.
Evalua tu librería
A la hora de decidir si introducir una nueva librería en un proyecto siempre me hago las siguientes 5 preguntas. Podéis considerarlas como un checklist que os ayudará a discernir si os compensa ejecutar npm install o no.
¿Es realmente necesaria en mi proyecto?
Hay veces que instalamos nuevas librerías por vicio. Intento no generalizar, pero yo soy el primero que antes de plantear cómo resolver un problema, tiendo a mirar si ya existe una librería que lo resuelva. Disponer de esta librería es una ventaja, pero a su vez, eso implica el ir atando nuestro proyecto a librerías que esperamos que funcionen correctamente y que lo hagan así para siempre.
Es importante parar un momento y pensar cómo solventar los problemas que nos vamos encontrando. Esto nos ayudará a reducir dependencias innecesarias y a mejorar como desarrolladores. Un ejemplo es este pull request que hice hace un año. Agregando un par de líneas de código fui capaz de eliminar una dependencia del proyecto.
Si realmente concluimos que es necesaria una librería, podemos plantear si necesitamos esa librería al completo. Una buena opción puede ser la de extraer la únicamente funcionalidad que es necesaria. Lodash sigue este patrón, permitiendo incluir sólo las funciones necesarias para tu proyecto.
¿Dónde está la caca, Robin?
Otro aspecto muy importante que hay que tener en cuenta es que instalar una librería no es simplemente instalar un paquete, sino que implica instalar todo su árbol de dependencias. Y no son pocas. Os pongo de ejemplo el código fuente de mi proyecto https://rand.fun. Según el fichero package.json, mi proyecto tiene 15 dependencias. No obstante, al contar las dependencias instaladas en node_modules el resultado es de 709.
Os recomiendo la herramienta http://npm.anvaka.com/ para visualizar todas las dependencias de un proyecto. Siguiendo el ejemplo mostrado en el apartado anterior, con el pull request no eliminé una dependencia, sino tres.
Otra herramienta muy útil es bundlephobia. Esta nos muestra lo que ocupa la librería al agregarla a nuestro proyecto. Esto es especialmente importantes para librerías que acabarán en el cliente. Cuanto mayor sea el tamaño, pero será la experiencia de tus usuarios ya que el tiempo de carga será mayor.
¿Qué ocurre si falla?
Jeremy Keith planteó una pregunta similar en su charla "Evaluating Technology". Un error es enfocar la evaluación de una librería solamente pensando en su funcionalidad.
¿Qué ocurre si falla? Es decir, qué coste tiene para nuestra aplicación que una librería falle. ¿La aplicación deja de funcionar? ¿Los usuarios reciben un error cuando acceden a una URL en concreto?
Pongamos como ejemplo una aplicación que tiene que hacer llamadas a una API externa. Imagina que estamos evaluando el uso de una librería que implementa su propio cliente de peticiones HTTP frente a la librería nativa fetch. A igualdad de funcionalidades, siempre deberemos optar por fetch. Si la otra librería empieza a fallar tras una actualización, toda nuestra aplicación deja de funcionar y se vuelve una interfaz sin lógica. En otras palabras, esa librería falla mal.
Plantear qué ocurre cuando una librería falla nos ayuda a ver más claramente los riesgos que estamos asumiendo. Una manera de reducir dichos riesgos es mediante el testing.
Si la librería está correctamente testada, esto reduce en gran medida la posibilidad de que falle. No olvidéis comprobar cómo está testada una librería cuando la estéis evaluando.
¿Cómo es su comunidad?
Para analizar la comunidad de una librería suelo guiarme por su web y su repositorio en GitHub. Estos sitios web suelen ofrecer mucha información sobre el mantenimiento de una librería y cómo la gestionan los colaboradores.
Lejos de quedarte en las estrellas de un repositorio, las secciones de Issues y Pull requests ofrecen mucha más información. Que discusiones hay y cuántas se han solucionado, son datos que nos dan una buena idea de la gestión de la librería. Esto es tremendamente útil para librerías con muchos colaboradores.
Por el contrario, que los colaboradores u otros usuarios no resuelven dudas o no se cierren los Pull Requests puede ser un indicador de que algo va mal. Cuando un proyecto empieza a desatenderse significa que pronto dejará de recibir soporte a nuevas funcionalidades y actualizaciones. También hay que tener en cuenta que hay librerías que cumplen su cometido de forma eficiente y no necesitan ser actualizadas constantemente. Por ello, no olvidéis mirar qué ocurre con las Issues abiertas 😉.
¿Podría continuar su desarrollo?
Podríamos reescribir la pregunta de otra manera: ¿entiendo el código y cómo funciona? El que una librería deje de ser mantenida es un problema que puede ocurrir. Hay proyectos que se mantienen durante muchos años y otros que se abandonan a los pocos meses.
Entender el código reduce en gran medida el impacto del abandono de una librería. Esto nos permite realizar una copia del proyecto y continuar contribuyendo por tu cuenta. Mi recomendación es que no tengáis miedo de echar un vistazo al código fuente de una librería. No hace falta comprender cómo funciona al completo, pero el estilo, la organización y la documentación ofrecen una buena idea de cómo está desarrollada.
Para mi, la documentación es un bien escaso que debemos de valorar en un proyecto. La presencia de buena documentación generalmente implica que el código está bien estructurado. Si el código está bien documentado, no tendréis ningún problema para continuar con su desarrollo.
Es bueno pararse a pensar
El disponer de un abanico de librerías es una gran ayuda y algo que me encanta del ecosistema OpenSource. No obstante, es importante tenerlas en mente como una posible solución y no como un parche rápido para solventar cada problema que se nos plantea.
En este artículo hemos puesto como ejemplo el ecosistema de Nodejs y NPM, pero esto aplica a todos los lenguajes y gestores de paquetes. A partir de ahora, no olvidéis haceros estas preguntas cada vez que penséis en instalar una nueva librería:
- ¿Es realmente necesaria?
- ¿Dónde está la caca, Robin?
- ¿Cómo falla?
- ¿Qué tal es su comunidad?
- ¿Podría continuar su desarrollo?