Menys dependències, sistemes més sòlids

Hi ha una seducció en el desenvolupament de programari modern. Per a cada problema, hi ha un paquet. Per a cada punt de fricció, un connector. Ens tempta la promesa de velocitat immediata: “Només instal·la això i el problema està resolt”.

A curt termini, la promesa es compleix. La funcionalitat s’entrega. El tiquet passa a “Fet” i ens sentim productius.

Però el programari no és un artefacte estàtic; és un sistema viu. Quan avaluem el cost d’una funcionalitat, sovint només calculem el temps per desenvolupar-la. Ometem el cost molt més gran: el temps per mantenir-la funcionant. El manteniment de programari principal no consisteix a arreglar errors de la teva pròpia lògica, sinó a gestionar la fricció de les teves dependències.

Com més codi extern importes, menys propietari ets del teu sistema.

La dependència és deute

Cada dependència —ja sigui una petita utilitat, un framework d’UI o un servei de tercers— és un contracte. Intercanvies control per comoditat. Acceptes un lloguer de manteniment permanent a canvi d’un impuls de velocitat temporal.

Considera el cicle de vida d’una dependència significativa.

• Dia 1: Resol el problema perfectament. L’equip està content.
• Any 1: La biblioteca llança un canvi incompatible (v2.0). Has de pausar la feina nova per refactoritzar el teu codi, o triar quedar-te en una versió sense suport.
• Any 3: El mantenidor perd l’interès o la comunitat es mou a una eina “més nova i millor”. Els problemes s’acumulen. Apareixen vulnerabilitats de seguretat. Ara ets propietari d’aquest codi, l’entenguis o no.
• Any 5: La biblioteca entra en conflicte amb un altre sistema central que necessites actualitzar. Estàs encallat. El “temps estalviat” fa cinc anys s’ha pagat amb interessos.

Aquest és el cost operatiu ocult de la complexitat. Un sistema àgil amb codi base propi i fonamental pot trigar un 20% més a desenvolupar-se inicialment. Però un sistema pesat construït sobre una torre d’abstraccions requerirà un 200% més d’esforç per mantenir-se viu durant una dècada.

Sovint assumim que les biblioteques “estàndard” són més segures que el codi propi. Però a llarg termini, l’únic codi en què realment pots confiar és el que pots llegir, depurar i arreglar tu mateix.

La il·lusió de la modularitat

Ens diem a nosaltres mateixos que les biblioteques fan el nostre codi més modular. A la pràctica, sovint introdueixen “codi d’integració”: la lògica desordenada i fràgil necessària per fer que dos sistemes obstinats parlin entre ells.

Quan depens fortament de dependències, el teu equip deixa de resoldre el problema de negoci i comença a resoldre el “problema d’integració”. Passes els teus dies lluitant contra fitxers de configuració, incompatibilitats de versions i errors foscos enterrats en una carpeta node_modules.

A més, les dependències augmenten la càrrega cognitiva per a cada nou enginyer. En lloc d’aprendre el llenguatge i el teu domini, han d’aprendre el llenguatge, el teu domini i les idiosincràsies de l’API d’una dotzena d’eines de tercers.

Principis per a un sistema més fort

Això no és un argument a favor de reinventar la roda. No hauríem d’escriure la nostra pròpia criptografia, bases de dades o protocols de xarxa de baix nivell. No obstant això, la postura d’enginyeria per defecte hauria de ser l’escepticisme, no l’adopció.

Aquí hi ha alguns principis per guiar aquesta decisió:

1. Prefereix la plataforma

Els navegadors i els sistemes operatius són potents. CSS, JavaScript i les utilitats estàndard de Linux han evolucionat eficaçment. Abans de recórrer a una biblioteca pesada per gestionar dates, animacions o formularis, pregunta’t: “Pot el navegador fer això nativament?”

Sovint, l’API estàndard és més estable, més eficient i té garantia d’existir en deu anys. La biblioteca no. La plataforma és la dependència definitiva; recolza’t en ella.

2. Sigues propietari del camí crític

Si una peça de lògica és central per al teu valor únic, probablement l’hauries d’escriure tu mateix. Externalitzar el teu domini principal a una biblioteca genèrica significa que estàs limitat per les decisions de disseny d’una altra persona. Quan les teves necessitats divergiran de les seves, et trobes amb un mur.

Si el teu producte és un tauler de control, no deleguis la lògica de gràfics a una abstracció d’alt nivell que oculta el bucle de renderitzat. Sigues propietari del que et fa valuós.

3. Avalua l’estratègia de sortida

Abans d’executar npm install o pip install, pregunta: “Si hagués d’eliminar això en dos anys, com de difícil seria?”

Si una dependència crea una teranyina generalitzada a través de la teva base de codi, és un matrimoni d’alt risc. Si s’assenta darrere d’una interfície que controles, és una eina manejable. Aïlla les teves dependències perquè puguis reemplaçar-les sense reescriure la teva aplicació.

4. L’avorrit és resilient

Les noves eines floreixen i es marceixen. L‘“stack modern” de 2020 ja sembla antiquat avui. SQL, HTML i HTTP són avorrits. També són atemporals.

Construir sobre tecnologia avorrida és la millor manera d’assegurar que el teu sistema sobrevisqui al cicle de “hype”. “Avorrit” significa que existeix documentació. “Avorrit” significa estabilitat. “Avorrit” significa que dorms a les nits.

El joc a llarg termini

Necessitem canviar el nostre pensament de “com de ràpid podem construir això?” a “quant de temps podem mantenir això?”

La complexitat és l’assassí silenciós dels projectes digitals. Es cola, paquet a paquet, fins que el sistema esdevé massa car de canviar i massa fràgil de tocar. Els sistemes més forts són sovint els que tenen menys parts mòbils. Són més fàcils d’assegurar, més fàcils d’optimitzar i més fàcils de traspassar a la següent generació d’enginyers.

Cada vegada que afegim una dependència, estem convidant un estrany a casa nostra. Implica confiança. Implica una relació a llarg termini. Hauríem de ser molt més previnguts per signar aquests contractes.

En un món obsessionat amb noves eines, la decisió d’enginyeria més avançada és sovint l’elecció d’utilitzar-ne menys.