Lo scorso anno è apparso su Medium un articolo intitolato “How it feels to learn JavaScript in 2016“. Il post è un divertente J’accuse a tutto il mondo dello sviluppo frontend moderno. Il post è diventato in breve tempo abbastanza virale, rimbalzando su vari profili Twitter dedicati al mondo JavaScript. Questo è solo uno dei tanti post / talk / video che trattano dell’argomento JavaScript Fatigue.
La JavaScript Fatigue è un termine che si usa per indicare la difficoltà di stare al passo con tutte le novità del mondo JavaScript. Ci sono ad oggi una pletora di framework e tool da padroneggiare per potersi definire un frontend engineer. Personalmente vivo questa cosa non come un fastidio ma come un’enorme opportunità. Da grande appassionato di software architecture ogni volta che ho la possibilità di analizzare un nuovo framework cerco di cogliere a quali pattern o paradigmi fa riferimento e cerco poi applicare le stesse metodologie nei casi d’uso che ritengo opportuni.
Ma è un dato di fatto che ogni riga di codice scritta oggi rischia di diventare obsoleta dopo appena un anno. Per questo motivo in Flowing stiamo un utilizzando un approccio “difensivo” rispetto ai framework, quando questo si sposa con gli obiettivi di business del cliente. Per approccio difensivo intendiamo l’attenzione ad utilizzare di un framework solo le parti di cui abbiamo effettivamente bisogno in quel momento. Questa metodologia si ricollega al concetto di Sacrificial Architecture che ho trattato in maniera approfondita in vari talk lo scorso anno. Il framework quindi deve sempre essere una dipendenza il più possibile sacrificabile quando non risponde più alle esigenze di un progetto.
Un altro approccio è quello di evitare del tutto l’utilizzo di framework di qualsiasi tipo. Questo approccio lo abbiamo chiamato Frameworkless Frontend Development. Al contrario di quanto si possa pensare, scrivere un’applicazione senza framework non è né un’operazione eccessivamente complessa, né un’operazione eccessivamente costosa. Ovviamente però avrete bisogno di un team di frontend engineer esperto e che conosca come manipolare efficacemente il DOM. Se siete curiosi potete dare un’occhiata a questo progetto su GitHub fatto senza nessun tipo di dipendenza. Noterete che in realtà il codice è assolutamente leggibile anche se scritto senza l’ausilio di nessuna libreria di terze parti.
Ma a parte la possibilità effettiva di poter scrivere un’applicazione in maniera Frameworkless, quando è giusto questo tipo di approccio? Oppure in maniera più generica come si sceglie un framework e soprattutto come capire da quali features è saggio “difendermi”? Se ad esempio scegliamo di “reinventare la ruota” nel progetto o con il team sbagliato il nostro progetto potrebbe finire così:
Questo tipo di problema non si può risolvere solo con analisi tecniche, ma occorre soprattutto un dialogo con il cliente. Per poter prendere questo tipo di scelte strategiche bisogna avere chiaro in mente quali sono gli obiettivi di business del progetto. Proprio per questo riteniamo indispensabile la nostra discovery per poter dare le risposte giuste ai nostri clienti. Personalmente poi trovo molto utile un piccolo esercizio che utilizziamo spesso proprio durante la discovery: il gioco delle leve.
Lo svolgimento è abbastanza semplice: chiediamo ai nostri clienti di mettere in ordine di importanza queste 4 voci, senza la possibilità di parimerito.
Come capite il framework scelto non può essere lo stesso se il cliente afferma che il suo ordine di importanza è Qualità/Scope/Budget/Deadline o se invece vi dice Deadline/Qualità/Budget/Scope. Utilizzare questo tipo di informazioni diventa quindi fondamentale per conosce il contesto che ruota intorno al nostro software, e il contesto è una variabile che non possiamo ignorare nella scelta di una tecnologia.
Ovviamente tutte queste scelte non devono essere scolpite nella pietra ma devono essere messe in discussione in continuazione. In questo ci viene in aiuto il nostro metodo iterativo. Al variare degli obiettivi del cliente, devono variare le specifiche e attorno a queste nuove specifiche dobbiamo costruire la migliore architettura possibile. Perché il codice che scriviamo è esclusivamente uno strumento che deve generare valore per i nostri clienti.
Per uno dei nostri clienti più importanti stiamo virando verso un approccio Frameworkless. La nostra applicazione è stata costruita con il framework AngularJS per i primi anni di sviluppo. Questo perché d’accordo con il nostro cliente l’obiettivo era ottenere il prima possibile un prodotto testatbile per avere un feedback da parte degli utenti. Oggi il progetto è un asset portante dell’azienda e quindi abbiamo dovuto cambiare prospettiva, in questo momento l’obiettivo primario è garantire che il software cresca in maniera sana per altri molti anni. Abbiamo quindi deciso di iniziare a scrivere una Strangler Application basata su EcmaScript 6 e Web Components. Dato che dobbiamo tenere in considerazione una visione di lungo periodo – anzi lunghissima se teniamo in considerazione il ciclo di vita di applicazioni frontend – abbiamo deciso di abbandonare il maggior numero di librerie esterne che fra qualche anno potrebbero non essere più utilizzata o mantenute.
Ho condensato tutti questi ragionamenti in un talk che ho portato al Codemotion Berlino di quest’anno e che sto per portare a Codemotion Milano. Ovviamente l’argomento è vasto e complesso quindi, per chi volesse approfondire, stiamo preparando un workshop di due giorni per Avanscoperta di cui potete leggere tutte informazioni sulla scheda formazione del loro sito ufficiale.
