Compromisos i Restriccions
Cada dependència és una aposta
Triar una llibreria o framework no és una decisió purament tècnica. És un compromís a llarg termini amb conseqüències que s'acumulen amb el temps.
4 min
Cada dependència que afegeixes a un projecte és una aposta.
Estàs apostant que la llibreria es mantindrà. Que l’API romandrà estable. Que la comunitat sobreviurà un canvi de titularitat o un gir de moda. Que les vulnerabilitats de seguretat seran pegades. Que algú al teu equip la continuarà entenent d’aquí a tres anys.
La major part del temps, l’aposta surt bé. Però els termes rarament es llegeixen amb cura.
El contracte ocult
Quan afegeixes una dependència, no estàs simplement afegint funcionalitat. Estàs adoptant un contracte.
El contracte diu: farem servir les abstraccions d’aquesta llibreria com a base d’una part del nostre sistema. L’actualitzarem quan canviï. Depurarem els problemes que s’originin al seu interior. La monitoritzarem per cercar vulnerabilitats. Ens n’allunyarem si es torna inviable.
Aquest contracte no està escrit en cap lloc. No apareix a la descripció del pull request. Però és real, i s’acumula. Una base de codi amb cinquanta dependències té cinquanta contractes actius. Alguns d’aquests contractes acabaran sent cars.
El problema de l’acumulació
El cost d’una dependència s’acumula de maneres fàcils de subestimar.
Una dependència afegida l’any u encara hi és l’any quatre. Per llavors pot haver passat per tres versions principals. L’enginyer que la va introduir pot haver marxat. La justificació original pot ser que ja no sigui vàlida, o pot ser que ningú la recordi. L’equip ara manté alguna cosa que no va triar i que no entén del tot.
Pitjor encara, les dependències depenen de dependències. L’ecosistema npm va fer famós aquest mode de fallada: un projecte simple pot arrossegar centenars de dependències transitives, la majoria de les quals ningú a l’equip ha llegit mai. Cadascuna és un risc latent.
La pregunta no és només “és bona aquesta llibreria?” La pregunta és “estem preparats per ser propietaris de tot el que aquesta llibreria porta amb ella?”
La trampa de construir vs. usar
Hi ha un mode de fallada comú en la direcció oposada: construir des de zero coses que haurien de ser una dependència.
Autenticació, xifratge, anàlisi de dates, enviament de correus electrònics: aquestes són àrees amb requisits ben entesos i solucions ben provades. Construir-les tu mateix rarament produeix un resultat millor. Produeix una implementació a mida que està menys provada, menys revisada i és més difícil d’actualitzar.
La decisió no és “dependència o no dependència.” La decisió és sobre quin tipus de risc és més acceptable: el risc del canvi extern, o el risc de la falta d’inversió interna.
La lògica de domini principal hauria de ser completament teva. El codi d’infraestructura i utilitats, normalment no.
Un procés més deliberat
Abans d’afegir una dependència, val la pena fer-se algunes preguntes.
Està aquesta llibreria activament mantinguda? No només actualitzada recentment, sinó genuïnament mantinguda: problemes atesos, vulnerabilitats pegades, un full de ruta que tingui sentit per a on va el teu sistema.
Quin és el cost d’abstracció? Una dependència que filtra els seus interns per tota la base de codi és molt més cara de substituir que una que seu darrere d’una interfície clara. Si no pots establir un límit al seu voltant avui, no podràs eliminar-la demà.
Quin és el camí de migració si això surt malament? Si la llibreria és abandonada o introdueix un canvi que trenca la compatibilitat, com de difícil és allunyar-se’n? Si no pots respondre aquesta pregunta amb confiança, la dependència té més risc del que sembla.
Podria una llibreria més petita i enfocada fer el mateix treball? Els frameworks grans sovint porten capacitats que mai no faràs servir i restriccions que acabaràs lamentant.
Les dependències com a decisions arquitectòniques
El graf de dependències d’un projecte és un document arquitectònic. Descriu en quins sistemes externs confia el projecte, quines abstraccions ha adoptat i amb quines comunitats està acoblat el seu manteniment.
La majoria dels equips no el tracten així. Les dependències s’afegeixen quan es necessiten i s’obliden quan deixen de ser noves. El graf creix en una sola direcció.
Un enfocament més deliberat tracta cada dependència com una elecció amb un cost conegut i un propietari conscient. No totes les dependències es poden avaluar perfectament: el món es mou ràpid i els terminis són reals. Però la postura de tractar les dependències com a apostes, en lloc de com a funcionalitat gratuïta, produeix millors sistemes amb el temps.
Cada aposta finalment es liquida. La pregunta és si entenies les probabilitats quan la vas fer.