Compromisos y Restricciones
Cada dependencia es una apuesta
Elegir una librería o framework no es una decisión puramente técnica. Es un compromiso a largo plazo con consecuencias que se acumulan con el tiempo.
4 min
Cada dependencia que añades a un proyecto es una apuesta.
Estás apostando a que la librería se mantendrá. A que la API permanecerá estable. A que la comunidad sobrevivirá un cambio de titularidad o un giro de moda. A que las vulnerabilidades de seguridad serán parcheadas. A que alguien en tu equipo la seguirá entendiendo dentro de tres años.
La mayor parte del tiempo, la apuesta sale bien. Pero los términos rara vez se leen con cuidado.
El contrato oculto
Cuando añades una dependencia, no estás simplemente añadiendo funcionalidad. Estás adoptando un contrato.
El contrato dice: usaremos las abstracciones de esta librería como base de una parte de nuestro sistema. La actualizaremos cuando cambie. Depuraremos los problemas que se originen en su interior. La monitorizaremos en busca de vulnerabilidades. Nos alejaremos de ella si se vuelve inviable.
Este contrato no está escrito en ningún sitio. No aparece en la descripción del pull request. Pero es real, y se acumula. Una base de código con cincuenta dependencias tiene cincuenta contratos activos. Algunos de esos contratos acabarán siendo caros.
El problema de la acumulación
El coste de una dependencia se acumula de maneras fáciles de subestimar.
Una dependencia añadida en el año uno sigue ahí en el año cuatro. Para entonces puede haber pasado por tres versiones principales. El ingeniero que la introdujo puede haberse ido. La justificación original puede que ya no sea cierta, o puede que ya no se recuerde. El equipo ahora mantiene algo que no eligió y que no entiende del todo.
Peor aún, las dependencias dependen de dependencias. El ecosistema npm hizo famoso este modo de fallo: un proyecto simple puede arrastrar cientos de dependencias transitivas, la mayoría de las cuales nadie en el equipo ha leído jamás. Cada una es un riesgo latente.
La pregunta no es solo “¿es buena esta librería?” La pregunta es “¿estamos preparados para ser dueños de todo lo que esta librería trae consigo?”
La trampa de construir vs. usar
Hay un modo de fallo común en la dirección opuesta: construir desde cero cosas que deberían ser una dependencia.
Autenticación, cifrado, parseo de fechas, envío de correos electrónicos: estas son áreas con requisitos bien entendidos y soluciones bien probadas. Construirlas tú mismo rara vez produce un resultado mejor. Produce una implementación a medida que está menos probada, menos revisada y es más difícil de actualizar.
La decisión no es “dependencia o no dependencia.” La decisión es sobre qué tipo de riesgo es más aceptable: el riesgo del cambio externo, o el riesgo de la falta de inversión interna.
La lógica de dominio principal debería normalmente ser de tu propiedad completa. El código de infraestructura y utilidades, normalmente no.
Un proceso más deliberado
Antes de añadir una dependencia, vale la pena hacerse algunas preguntas.
¿Está esta librería activamente mantenida? No solo actualizada recientemente, sino genuinamente mantenida: problemas atendidos, vulnerabilidades parcheadas, una hoja de ruta que tenga sentido para adonde va tu sistema.
¿Cuál es el coste de abstracción? Una dependencia que filtra sus internos por toda la base de código es mucho más cara de reemplazar que una que se sienta detrás de una interfaz clara. Si no puedes establecer un límite alrededor de ella hoy, no podrás eliminarla mañana.
¿Cuál es el camino de migración si esto sale mal? Si la librería es abandonada o introduce un cambio que rompe la compatibilidad, ¿qué tan difícil es alejarse de ella? Si no puedes responder esa pregunta con confianza, la dependencia tiene más riesgo del que parece.
¿Podría una librería más pequeña y enfocada hacer el mismo trabajo? Los frameworks grandes a menudo traen capacidades que nunca usarás y restricciones que acabarás lamentando.
Las dependencias como decisiones arquitectónicas
El grafo de dependencias de un proyecto es un documento arquitectónico. Describe en qué sistemas externos confía el proyecto, qué abstracciones ha adoptado y con qué comunidades está acoplado su mantenimiento.
La mayoría de los equipos no lo tratan así. Las dependencias se añaden cuando se necesitan y se olvidan cuando dejan de ser nuevas. El grafo crece en una sola dirección.
Un enfoque más deliberado trata cada dependencia como una elección con un coste conocido y un propietario consciente. No todas las dependencias pueden evaluarse perfectamente: el mundo se mueve rápido y los plazos son reales. Pero la postura de tratar las dependencias como apuestas, en lugar de como funcionalidad gratuita, produce mejores sistemas con el tiempo.
Cada apuesta finalmente se liquida. La pregunta es si entendías las probabilidades cuando la hiciste.