Framework vs Librerie: cosa scegliere per sviluppare la tua applicazione mobile

Pubblicato da IQUII il 13/12/2017 in Thinking

Una parte importante dello sviluppo software odierno ha origine nella scelta degli strumenti giusti per portare alla realizzazione di un’idea.

In questa prima fase di analisi la corretta scelta di una tecnologia rispetto ad un’altra rappresenta un momento fondamentale spesso in grado di delineare non solo il time to market del prodotto, ma anche le sue possibili evoluzioni nel tempo.

Come sviluppatori ci si trova spesso nella posizione di utilizzatori di questi strumenti (commerciali o open source) e solo raramente nella veste di chi quei tool li disegna, li realizza e li fa evolvere.

L’idea di questo articolo nasce proprio dalla volontà di spingersi, seppur superficialmente, in un universo spesso inesplorato, delineando differenze tra framework e librerie e fornendo alcuni consigli per chi vuole o si trova nella condizione di dover realizzare qualcosa che per una volta sarà destinato ad altri colleghi e non ad utenti finali.

Librerie vs Framework: come scegliere il giusto strumento

Esistono sostanziali differenze, sia per design che nella realizzazione, per un codice il cui scopo è fornire una funzionalità a livello applicativo (application code) o all’interno di un modulo indipendente (framework/libreria).

Come è facile immaginare framework/librerie hanno lo scopo di fornire servizi facilmente riutilizzabili incapsulando, mediante una astrazione ad alto livello, complessità e ridondanze inutili.

Tipicamente questi moduli entrano a far parte della struttura interna del programma e, al netto di upgrade occasionali, forniscono una solida base per la crescita del prodotto stesso.

Sarà proprio compito del codice applicativo utilizzare queste astrazioni al fine di ottenere comportamenti e interazioni logiche complesse tra gli utenti e i dati applicativi, calando un comportamento generale all’interno di una situazione più concreta e limitata.

In questo senso, mentre il codice applicativo è spesso oggetto di refactoring ed evoluzioni, framework e librerie tendono a rimanere una parte poco mutevole e più strutturale di ogni progetto; la necessità di avere “building block“ stabili non è solo quindi una questione di igiene del codice ma una esigenza in grado di segnarne inevitabilmente gli sviluppi futuri.

A tal proposito c’è una citazione di Dave Clayton che riassume molto bene la situazione che tutti gli sviluppatori vivono nel loro quotidiano lavoro con il codice; in italiano suona più o meno così:

“Nella programmazione alla fine tutto si riduce ad una sola cosa: la scelta degli strumenti giusti. Al giorno d’oggi gli sviluppatori si trovano a fronteggiare una pletora di opzioni a disposizione che spesso vanno ben oltre le loro necessità: avete mai sentito parlare del paradosso della scelta? Riassume egregiamente il mondo IT.  Scegliere tra framework o libreria è soltanto una delle domande a cui dobbiamo rispondere, ma probabilmente, tra tante, è la più importante. Un team formato da molti elementi junior si troverà a preferire un framework per via della struttura rigida e delle regole che impone. Sviluppatori senior invece apprezzeranno meglio la flessibilità e la libertà offerta dalle librerie.”

Di seguito vedremo nel dettaglio cosa differenzia framework e librerie e come scegliere l’una rispetto all’altra a seconda delle nostre esigenze.

Il livello applicativo

Il livello applicativo è dove le funzionalità astratte “sfociano” in una realizzazione concreta: è il punto in cui tutte le entità e i comportamenti definiti realizzano il prodotto e dove le informazioni e le nostre azioni plasmano i dati.
In qualità di sviluppatori è la parte dove spendiamo gran parte del nostro lavoro.

Generalmente in questo livello deve risiedere solo il codice strettamente rilevante al dominio applicativo.
Se, muovendoci tra progetto e progetto ci accorgiamo che stiamo usando (magari anche copia-incollando) lo stesso codice, probabilmente ci troviamo nel momento giusto in cui poter valutare l’opzione di una maggiore astrazione.

È di fondamentale importanza comprendere il motivo principale di questa scelta. Duplicare il codice significa:

• creare più punti di deboli;
• aumentare le chance di commettere errori;
• incrementare esponenzialmente l’effort dedicato al suo mantenimento ed evoluzione.

 

Lavorando a livello applicativo sarà nostra cura scegliere innanzitutto il giusto paradigma di sviluppo; sicuramente il più famoso è MVC – model view controller. Chiaramente non è l’unico e, anzi, negli ultimi anni una pletora di alternative (con relativi pro e contro) si è fatta spazio nel panorama architetturale: Viper, MMVM, Redux sono solo alcuni nomi. Fortunatamente questo non è l’ennesimo articolo di architetture.

Librerie vs Framework: è questione di controllo

La differenza chiave tra libreria e framework può essere riassunta in un solo termine: IoC o Inversion Of Control:

• utilizzando una libreria controlliamo noi il flusso codice;
• utilizzando un framework accettiamo il fatto di essere noi (la nostra applicazione) ad essere utilizzati. E’ come il principio di Hollywood: “Don’t call us, We’ll call you“.

Ma cosa è una libreria?

Una libreria è sostanzialmente un set di funzioni organizzati per classi all’interno di uno o più scopi.

L’obiettivo di una libreria è quello di fornire del codice riusabile all’interno di una specifica area: le librerie hanno lo scopo di semplificare, spesso attraverso astrazioni, comportamenti e funzionalità complesse.

L’utilizzo corretto di librerie riduce sensibilmente la quantità di codice da scrivere e mantenere, offrendo spesso una base più testata e generica di un codice scritto ad hoc.

E un framework?

Un framework può essere definito come una architettura il cui scopo è quello di facilitare, attraverso l’imposizione di rigide regole, la realizzazione di software.

Un framework incapsula al suo interno regole e comportamenti che il prodotto può avere; possiamo immaginare un framework come un grande diagramma di flusso dove compaiono dei buchi vuoti che consentono di plasmarne il comportamento in base alle necessità del prodotto da realizzare.

In buona sostanza si tratta di avere a che fare con uno scheletro realizzato secondo una logica stringente e spesso composto al suo interno da più librerie.
Visto in questa ottica è il framework stesso a dettare l’architettura dell’applicazione: ne definisce vincoli (sia funzionali che applicativi), organizzazioni in classi/moduli, singole responsabilità di ogni componente e come esso interagisce con gli altri.

Framework o Librerie?

Nello sviluppo dell’architettura di un’applicazione, la scelta di utilizzare un framework piuttosto che una libreria dipende da vari fattori tra cui i tempi di sviluppo, la flessibilità del progetto, le preferenze del team di lavoro e le esigenze del prodotto.

Prima di rispondere a questa domanda, è necessario approfondire gli obiettivi che questi strumenti consentono di raggiungere.

“I framework enfatizzano il riuso del design sul riuso del codice”

Lo scopo ultimo di un framework è quello di “liberare” (è proprio il caso di aggiungere il virgolettato) il programmatore dall’incombenza di dover preparare una valida architettura, offrendone una generica che sarà però pagata al prezzo di una libertà di azione che può o meno essere giustificata a seconda del caso specifico.

È quindi chiaro come il vantaggio principale dei framework sia proprio quello di fornire una architettura di facile utilizzo dove fare plug-and-play dei comportamenti desiderati.

Chiaramente, come già accennato, tutto questo ha un prezzo, sia a livello umano (per chi sviluppa) sia a livello tecnologico:

• “I framework sono come un matrimonio: vanno bene fino a quando non iniziano ad andar male“.
  Scrivere un prodotto appoggiandosi ad un framework plasma invariabilmente l’architettura del prodotto: l’intero applicativo e le feature che potranno essere aggiunte sono strettamente dipendenti dai vincoli offerti.
  Non c’è un’uscita gratis di prigione, se non a caro prezzo: riscrivere tutto.
  Se state lavorando ad un prodotto con un tempo di vita medio lungo sarebbe opportuno ragionare molto su pro e contro di una scelta simile: considerando che attualmente i framework hanno una vita media di 1-2 anni potreste facilmente ritrovarvi nella situazione di non essere più supportati, alle prese con un codice ormai dismesso ed obsoleto (emblematico questo sito).

• I framework coltivano l’ignoranza.
  Utilizzare i framework nel proprio team può certamente portare vantaggi in termini di time to market.
  Purtroppo è però certo che il vostro team sarà vittima del “marketing da framework”, dove ogni soluzione ad un problema sia da trovare in un nuovo framework.
  Un team di sviluppo che non ha i fondamenti e che si affida al prossimo bottone magico non è il team che vorreste avere per crescere; a questo proposito un bellissimo articolo provocatorio è “Do Not Learn Frameworks: Learn Architecture” dove Alex Rboots afferma:

“Studying frameworks, you have to relearn, moving to new solutions that appear all the time, and a part of your experience will be erased. But when you learn principles — they stay.”

Come scrivere una buona libreria

Ormai vi sarà chiaro perchè sono tendenzialmente a favore delle librerie sui framework; pur essendo una scelta che va valutata da caso a caso (non ci sono mai risposte definitive) credo che, nell’ottica di lungo periodo, la scelta di progettazioni ad hoc coadiuvate dal supporto di librerie rappresenti ancora la soluzione migliore.

Negli ultimi anni mi sono occupato spesso di disegnare e progettare architetture e librerie; alcune di queste sono diventate prodotti open source, altre fanno parte delle aziende per cui ho lavorato.

In questa ultima parte vorrei condividere con voi alcuni principi base e consigli che vi saranno utili nel caso voleste o doveste aver bisogno di cimentarvi in questa nuova avventura.

1. Pensate sempre dalla prospettiva del programmatore: quando si disegna una libreria è facile cadere nella trappola di concentrarsi eccessivamente sull’implementazione, dimenticando poi l’effort necessario per l’apprendimento e l’uso. Tenete quindi sempre a mente lo scopo da ottenere. Un buon libro sull’argomento è “Domain-Driven Design: Tackling Complexity“;
2. Focalizzatevi sugli use-case: gli use-case definiscono come l’utente utilizzerà il vostro tool in casi reali e specifici. Realizzare una lista di priorità (sia essa per importanza o frequenza d’uso) di questi use-case è un ottimo modo per decidere cosa esporre nella maniera migliore: non si può rendere tutto facile, ma sicuramente rendere facile il caso più comune è senz’altro un giusto compromesso;
3. “Principle of least astonishment“: come Addy Osmani scrisse in un suo famoso post: “Try not to violate the principle of least astonishment, i.e. the users of your component API shouldn’t be surprised by behaviour. Hold this true and you’ll have happier users and a happier team”. (“Evitate comportamenti innaturali delle vostre API. I programmatori non devono essere sorpresi da comportamenti che difficilmente collimano con il raziocinio: le API devono essere ‘ovvie’ e ‘consistenti’ tra loro, perfettamente in linea con lo scopo ultimo della libreria”);
4. “Abstraction fails“. Ottenere l’astrazione definitiva per risolvere uno o più problemi complessi può essere una sfida persa in partenza: una buona conoscenza del problema può però aiutarvi portandovi sulla giusta strada. Anche qui, evitate di trovare la chiave di volta di tutto e concentratevi sul problema più importante. Un buon post sull’argomento l’ha scritto Joel On Software: “The Law of Leaky Abstractions“;
5. Non dimenticarti degli utenti pro: nascondere la complessità dietro grandi astrazioni potrebbe non essere sempre la decisione giusta: a volte lasciare agli utenti accesso ai dettagli più profondi della propria libreria può essere il giusto compromesso per non perdere flessibilità e ritrovarsi con decine di segnalazioni di programmatori frustrati;
6. Non sei Dio: alcuni problemi potrebbero essere troppo complessi per far parte di una sola soluzione; a volte dividere il problema in più sotto-problemi (più librerie) potrebbe essere il giusto compromesso.

Conclusioni

In questo percorso abbiamo visto come librerie e framework sono una parte fondamentale degli strumenti a disposizione degli sviluppatori, come poter scegliere tra le due soluzioni e quali sono i principi alla base di un buon design per un codice riusabile.

Anche se solo una piccola parte di voi avrà occasione di lavorare al design e la realizzazione di librerie, la conoscenza dell’argomento è un fattore di particolare rilevanza anche nella scelta consapevole degli strumenti da utilizzare.

Scegliere di utilizzare uno strumento piuttosto che un altro è una decisione che spetta a tutto il team di lavoro ed è strettamente correlata alla tipologia di prodotto o progetto che si intende sviluppare: saranno i tempi, il grado di flessibilità e le esigenze del prodotto stesso a guidare tale scelta che comporta, come abbiamo visto, vantaggi e inconvenienti in entrambi i casi.

Nella progettazione di software, la scelta migliore sarà quella che riuscirà meglio a valorizzare l’intero progetto adattandosi ai suoi vincoli e necessità per raggiungere gli obiettivi.