Questa settimana abbiamo il piacere di intervistare sul nostro blog Nicola Zaghini, Mobile Architect in Travelport Digital, sezione del famoso gruppo quotato a Wallstreet e che realizza Mobile App per le più grandi compagnie aeree. Da più di un anno Mango segue le sue linee guida adottando l’Architettura Software Mobile BViper ideata dal suo team per lo sviluppo di soluzioni mobile.

Domanda: Un’Architettura Mobile è maggiormente paragonabile ad una libreria da integrare o ad un strategia di sviluppo da seguire? Cosa significa implementare un’architettura mobile e quali sono i benefici che questa può apportare? Impatta il singolo sviluppatore o l’intero team aziendale?

Risposta: Quando si parla di architetture software per mobile si parla fondamentalmente di strategie codificate per lo sviluppo di applicazioni, in maniera del tutto analoga a quando si parla di architetture server per lo sviluppo di soluzioni server. Probabilmente il termine architettura è leggermente abusato in questa declinazione e design pattern o strategia sembra più attinente. Ad ogni modo senza essere troppo pignoli possiamo dire che l’architettura corretta ci aiuterà a sviluppare l’applicazione mobile con efficacia ed efficienza, mentre quella sbagliata ci sarà d’intralcio. Tutto sta nell’identificare l’architettura più corretta per le nostre esigenze: “No Size Fits All!”.

Quando iniziai a sviluppare per mobile, qualche anno prima che Steve Jobs presentasse il primo iPhone al mondo, era abbastanza normale lasciare al singolo sviluppatore l’inventiva “architetturale”. Lo sviluppo mobile era talmente una novità che era attivamente difficile fare meglio. Di certo Apple con l’introduzione del primo iOS non aiutò gli sviluppatori da questo punto di vista, anzi forse l’opposto, proponendo pattern o architetture con il solo scopo di attrarre più sviluppatori possibili sulla piattaforma in modo da creare massa critica in poco tempo. Oggi sarebbe abbastanza sciocco che ciò accadesse in quanto si sono affermate molte architetture o pattern validi per lo sviluppo mobile (MVVM, VIPER, Redux, React, …), ed anche Apple è diventata “bona maestra” spingendo gli sviluppatori a concentrarsi maggiormente sulla qualità del software prodotto.

Personalmente non ritengo che un’azienda debba per forza adottare un’unica architettura e forzarla a tutti i team, a meno che non operi in un dominio molto definito e di conseguenza le diverse applicazioni affrontino idealmente lo stesso problema (quindi un’unica soluzione architetturale sembra logica). Ad ogni modo ritengo che non debba mai essere una decisone del singolo sviluppatore ma quantomeno del team, se non addirittura aziendale nei casi descritti. L’ovvio vantaggio di una decisone aziendale sta nel fatto che la standardizzazione aiuta il ramp up di nuove risorse e la movimentazione delle stesse nei vari team. Bisogna però stare sempre molto attenti che la standardizzazione non porti alla stagnazione, soprattutto in business altamente dinamici e diversificati.

D: Si parla tanto di Viper nel settore come conseguenza della Clean Architecture ma voi proponete BViper: quali migliorie apporta questa vostra versione? Qual è stata l’esperienza di Travelport nell’adottarla?

R: VIPER è l’adattamento per mobile, nello specifico per iOS, della Clean Architecture proposta da Uncle Bob. Fu definita e proposta alla comunità da Mutual Mobile nel 2014. Fondamentalmente l’architettura VIPER aiuta la decomposizione di una Applicazioni in Moduli (che possiamo identificare con le singole schermate) codificando poi i componenti di questi moduli, in modo da ottenere componenti a singola responsabilità (principio ingegneristico molto importante e che comporta conseguenza alquanto interessanti).

Noi in Travelport Digital abbiamo aggiunto una B alla versione standard di VIPER (View – Interactor – Presenter – Entity – Router) in quanto durante lo sviluppo delle nostre applicazioni ci siamo resi conto della mancanza di un’astrazione che rappresentasse il “collante” di tutti questi componenti (che insieme realizzano un Modulo). Quindi abbiamo introdotto il concetto di Builder ovvero il componente che ha come unica responsabilità di creare e collegare tutti gli altri componenti di un Modulo.

L’adozione in Travelport Digital dell’architettura (B)VIPER non è stata “imposta”. Inizialmente è stata adottata dai team incaricati dello sviluppo di codice comune, riutilizzabile nei diversi prodotti, in quanto le proprietà di questa architettura sono molto utili al riuso del codice. Dopo di che, piano piano, anche tutti i team dedicati allo sviluppo di codice per i clienti hanno deciso autonomamente di muoversi verso questa architettura. Tra i commenti che ricordo con maggiore “affetto” da parte dei ragazzi dei vari team di sviluppo ci sono: “finalmente riesco a scrivere test in maniera semplice e veloce” (in TDD il codice non può essere rilasciato senza test) oppure “è molto facile capire dove mettere le mani nel codice di altri per aggiungere una funzionalità”.

D: Sappiamo che sei spesso in giro per il continente a parlare di BViper. Come risponde la comunità mobile in merito?

R: In realtà VIPER, e di conseguenza (B)VIPER, è una tra le architetture mobile più controverse. Essendo basata sulla Clean Architecture ha in se concetti che sono stati inizialmente pensati per il Web e per sistemi di dimensione “grande”, di conseguenza agli occhi di tanti risulta un approccio verboso o comunque non snello o se posso permettermi non “di tendenza”. Faccio un esempio. Una delle architetture più in voga per il dominio mobile del 2016 è sicuramente stata MVVM con l’utilizzo di estensioni Reactive. Era praticamente impossible trovarsi ad una conferenza di settore senza almeno un paio di talk su MVVM e RxSwift con piccole ma significative differenti declinazioni. Nei miei talk quello che io faccio è evincere VIPER da MVVM come sua generalizzazione. Quindi, seppure accolta ancora con qualche scetticismo, il numero di apprezzamenti e richieste di chiarimenti che ottengo sui vari social cresce di mese in mese.

D: Quanto può durare Viper e la vostra versione potenziata? Quali possono essere gli scenari futuri? Vedremo nascere nuove architetture oppure qualcosa a più alto livello?

R: Come detto in precedenza non esiste un’architettura in grado di risolvere ogni problema e le buone architetture non saranno mai obsolete, a meno che le applicazioni di domani non siano drammaticamente diverse da quelle di oggi.

Per fare un esempio sto ultimante studiando in maniera approfondita ReactNative che è la proposta di Facebook per lo sviluppo mobile “learn once, write everywhere”. Indipendentemente dalla dimensione del multi piattaforma e dell’utilizzo di Javascript come linguaggio di programmazione, il concetto base è che il livello (o componente) della Vista viene quasi completamente fuso con quello del Network, anche grazie a nuove ed interessanti tecnologie come GraphQL che abbattono virtualmente il concetto di API server. Quindi si afferma fondamentalmente che quello che una volta era considerato un errore (ovvero mescolare livelli di competenza in maniera del tutto deliberata) domani potrebbe essere il modo migliore di affrontare lo sviluppo mobile per alcuni specifici domini.