Trasmettere un tecnicismo al cliente è spesso un esercizio difficile ma qualche giorno fa, durante la mia attività giornaliera di learning, mi sono imbattuto in uno splendido articolo del team tecnico di Dropbox che risponde alla domanda: << perchè dovrei fare due app, una iOS ed una Android, se posso condividere parti del sorgente? >>.
Dropbox ha basato agli inizi la propria strategia sulla creazione di un codice sorgente unico in C++ in modo da poterlo condividere tra iOS ed Android. Questo permetteva di scrivere il codice una sola volta in C ++ anziché due volte, una Java e l’altra in Objective-C. Questa strategia era stata quasi “obbligata” dalla grandezza del team mobile (relativamente piccolo) e dalla rapidità di crescita che il progetto Dropbox doveva mantenere.
All’interno della repository di Steven Kabbes, sviluppatore di Mailbox, viene mostrato come realizzare codice sorgente in C++ che si interfacci con iOS ed Android.
Dopo diversi anni gli sviluppatori hanno deciso di abbandonare questa strategia e passare all’utilizzo del linguaggio nativo (principalmente Swift e Kotlin, entrambi introdotti relativamente poco tempo fa). Questa decisione è stata dettata dal costo nascosto associato alla condivisione del codice. Ecco alcune delle cose che il team di Dropbox ha imparato da questa esperienza.
Il sovraccarico di framework e librerie personalizzate
Il lavoro più oneroso da prevedere con C ++ è la necessità di creare framework e librerie. Possiamo grossomodo suddividerlo in due azioni:
- Framework per interagire con le funzionalità di sistema
- Librerie che sostituiscono funzionalità predefinite del linguaggio e/o standard open source che avrebbero potuto usare nel linguaggio nativo della piattaforma. Per esempio: libreria JSON per la (de)serializzazione
Il mondo “opensource” in C++, a cui Dropbox ha contribuito notevolmente https://opensource.dropbox.com/, è molto più limitato rispetto a quello dei linguaggi nativi ed inoltre al contrario di altri possibili linguaggi di programmazione non nativi, come Python o C#, in C++ manca di una singola libreria standard completa. C / C ++ sono gli unici linguaggi con un compilatore supportato sia da Google che da Apple, quindi l’uso di un linguaggio diverso avrebbe creato ulteriori problemi da affrontare.
Il sovraccarico di un ambiente di sviluppo personalizzato
L’ecosistema mobile ha molti strumenti disponibili per rendere lo sviluppo più efficiente. Gli IDE per dispositivi mobili sono molto ricchi e Google e Apple hanno investito molte risorse per renderli “moderni”. In particolare, l’esperienza di debug nella linguaggio nativo di una piattaforma è generalmente superiore al debug nel codice C ++ tramite l’IDE predefinito della piattaforma.
Il sovraccarico dovuto alle differenze tra le piattaforme
Entrambe le app iOS e Android sono “app mobili” che generalmente espongono le stesse caratteristiche e funzionalità ma le piattaforme stesse presentano alcune differenze che incidono sull’implementazione. Ad esempio, il modo in cui un’applicazione può eseguire attività in background su ciascuna piattaforma è diverso. La gestione di alcune funzionalità native (es. l’interazione con il rullino fotografico) nel tempo si è notevolmente differenziata tra iOS ed Android.
Il sovraccarico di formazione, assunzione e fidelizzazione degli sviluppatori
Ultimo, ma sicuramente non meno importante, è il costo della formazione e / o dell’assunzione di sviluppatori per lavorare su uno stack così personalizzato. Quando Dropbox ha iniziato con questa strategia mobile, aveva un gruppo centrale di sviluppatori C ++ esperti. Man mano che gli ingegneri hanno migrato verso altre società è nata una vera e propria carenza di persone nel team.
Diversi sviluppatori di talento hanno abbandonato il team perchè non interessati a lavorare su uno stack così specifico e fuori dal linguaggio di programmazione nativo.
Bilancio costi e benefici
Alla fine di questa esperienza il team di Dropbox si è reso conto che i costi per la condivisione del codice erano più dei reali benefici. Oltre alla complessità dovuta al C/C++ uno degli aspetti più rilevanti per le aziende odierne che sono molto attente ai bisogni del propri collaboratori è stata proprio la migrazione di quest’ultimi ad altre aziende perchè non affascinati da uno stack di fatto poco lontano dalla modalità di scrittura del codice nativa.