Di Jimit Shah
Fin dalla sua nascita, l'industria IT si è evoluta ogni giorno, offrendo esperienze tecnologiche superiori e sempre più impressionanti agli utenti finali.
D'altra parte, l'industria si è anche continuamente concentrata sulla riduzione del tempo e del ciclo di sviluppo per i team di ingegneria del software.
Una parte significativa degli ingegneri IT e delle organizzazioni sono motivati a facilitare il processo di sviluppo. Questo a sua volta è diventato una corsa a dare le migliori tecnologie (framework, strumenti, ecc.) ai team di ingegneri.
In questa corsa, la loro attenzione si è gradualmente spostata dalla "facilità di sviluppo" a quasi "nessuno sviluppo", cioè la creazione di strumenti che permettono agli ingegneri di integrare semplicemente le cose per fornire il prodotto finale. Essenzialmente, plug and play.
Naturalmente, i benefici che ne derivano sono:
Ora le aziende che stanno costruendo software per le imprese possono concentrarsi di più sulle idee di business.
Con un ciclo di sviluppo ridotto, le aziende possono costruire molti più prodotti software.
Tuttavia, la preoccupazione inizia quando gli ingegneri, che si abituano agli strumenti plug & play, iniziano a perdere competenze ingegneristiche fondamentali come l'ottimizzazione, la maturazione e l'architettura del codice.
Per esempio, nella prima era della costruzione di app native Android, gli ingegneri dovevano concentrarsi sul miglioramento di varie schermate di elenco ottimizzando il consumo di memoria. Ora, il framework Android stesso ha fornito views così mature che gli sviluppatori hanno solo bisogno di integrarle nel sistema.
Oppure possiamo guardare qualcosa come Flutter, che ha reso lo sviluppo di app semplicissimo. Ma viziati da questa comodità, cerchiamo di capire come Flutter ci semplifica la vita? Andiamo “sotto il cofano”? Il più delle volte, non lo facciamo.
Abbiamo sviluppato una mentalità che privilegia la facilità di sviluppo delle applicazioni rispetto allo sviluppo di applicazioni migliori.
Questa eccessiva dipendenza dai framework plug & play porta anche gli ingegneri a seguire ciecamente le pratiche "raccomandate" dai giganti della tecnologia. Per esempio, quando Google ha iniziato a raccomandare il pattern MVVM, i team hanno iniziato ad implementarlo alla cieca, senza nemmeno capire il suo reale scopo o se sia addirittura rilevante per la loro applicazione.
Per fermare questo spreco di conoscenza, dobbiamo cercare di capire come la libreria/pacchetto/pod/gem che stiamo usando funziona effettivamente sotto il cofano. Dobbiamo cercare di capire come esattamente risolve i nostri problemi difficili e i compiti che richiedono tempo.
Questo ci permetterà di porci le domande più importanti come:
Se risolvo lo stesso problema, posso renderlo più ottimizzato? Posso farlo consumare ancora meno memoria? ... e altro ancora.
Questo ci aiuterà a costruire sistemi che sono molto meglio per le nostre esigenze. Questo aiuterà anche la nuova generazione di ingegneri a costruire una mentalità ingegneristica più forte.
P.S. Questo non significa che dobbiamo reinventare la ruota e limitarci ad usare framework/pacchetti tecnologici già disponibili, ecc. Piuttosto, mentre si usa qualsiasi tecnologia, capire come funziona e risolve il problema.