Perché ho scritto questo articolo

Spesso ricevo mail e messaggi di questo tipo:

“Bob, come faccio a diventare un developer?”

“Bob, voglio dare una svolta alla mia carriera. Mi piacciono i tuoi articoli e i tuoi video. Come posso diventare sviluppatore iOS?”

“Bob, non so da dove iniziare, non ho mai programmato prima. Puoi aiutarmi?”

Vi capisco, ma sarò sincero: detesto rispondere a domande generiche. È un po’ come chiedere che tempo fa fuori: non ha senso. Se fossero miei amici, probabilmente replicherei in tono sarcastico con il classico “L’hai cercato su Google?

Sono consapevole del fatto che rischio di esprimere un’opinione con dei limiti in questo articolo ma, almeno, quando la gente mi porrà domande di questo tipo avrò la possibilità di dire “leggi il mio articolo e fammi sapere se hai ulteriori dubbi”.

Disclaimer. Questo articolo potrebbe essere mosso dai miei pregiudizi, perché ne ho. Racconterò qui la mia esperienza personale, dal momento che Swift è il mio primo linguaggio di programmazione.

Relax e abc

Capisco. Quando ho iniziato a studiare iOS, in realtà pensavo solo di voler realizzare la più grande app di sempre. Ho acquistato corsi online e libri — del tipo “L’unico corso che ti serve per diventare un developer iOS di successo!” — mi sono fatto prendere da queste cose. Ma sono stronzate.

Non ho mai capito cosa significassero questi !, ?, as, if, let, keywords. Non ero altro che un code monkey. Copiavo dallo schermo come uno zombie. Se avete aperto questo articolo, il mio consiglio è il seguente: studiate Swift prima di tutto. Cacciamo via il pensiero di iOS, perché stiamo parlando dei fondamentali della programmazione. Per fare un’analogia, sarebbe un po’ come voler imparare a pubblicare un libro senza conoscere né grammatica né alfabeto.

Se non capite nessuno dei concetti Swift esposti di seguito, fate ricorso a quei simboli rossi sulla colonna sinistra di Xcode. Assicuratevi di comprendere:

delegate, extension, Protocol, optionals, super, generics, type casting, error handling, enum, closures, completion handlers, property observer, override, class vs struct

Non provate nemmeno per scherzo a tentare lo studio di programmazione funzionale e programmazione protocol-oriented se ancora non avete preso il pieno controllo della Programmazione Object-Oriented.

Non vi perdete tentando di capire tutto. Capite le basi.

Andare oltre le basi è possibile solo se avete familiarità con quei concetti Swift menzionati prima e, quindi, siete alle prese con lo studio dell’ecosistema iOS. Non è necessario conoscere tutto in iOS e, del resto, è una materia troppo vasta. Ci sono troppe classi e troppi framework da affrontare e dei quali noi developer non possiamo sapere più di tanto, visto che non sono open source.

Lo sviluppo iOS è un po’ come far funzionare un forno a microonde. Tutto ciò che dobbiamo fare è leggere le istruzioni… ma per leggere le istruzioni bisogna conoscere le parole e la sintassi. Ad esempio, per riscaldare si premono un paio di bottoni e il piattoo comincia a ruotare, mentre una luce giallognola proviene dal fondo.

È la stessa cosa, perché gli ingegneri Apple hanno voluto così. Da sviluppatori iOS, il vostro lavoro è capire il motivo per cui hanno scelto di fare in un certo modo. Restando sull’esempio del microonde, devo chiedere il motivo per cui la rotazione aiuta la cottura, non il funzionamento dell’elettromagnetismo (anche se potrebbe aiutare).

Esempio pratico. Mi chiedo perché gli ingegneri Apple implementano i delegate patterns e il MVC > ne capisco i motivi. Tutto qua, è così che funziona lo studio.

Imparare le API

Una volta appresi concetti come delegate e protocol, diventa molto più semplice leggere la documentazione API. Nonostante ciò, gran parte delle guide – come Bundle Programming Guide – sono ancora oggi scritte in Objective-C. Non preoccupatevi: potrete tranquillamente convertire Objective-C in Swift. Date un’occhiata qui.

Spesso dico che studiare le API è come imparare a guidare diverse tipologie di veicolo. Ad esempio, UITableView e UICollectionView potrebbero rappresentare una bicicletta e una moto. Usare NSURLSession per scaricare e caricare dati, invece, è come guidare una BMW. Creare un progetto open source corrisponde a pilotare un aereo.

Indipendentemente dal tipo di veicolo, tutti loro condividono dei principi fondamentali: ci sono acceleratori e freni, motori e carburante. Trovare i punti in comune può essere difficile, ma è del tutto normale. Più arduo è il compito, più grande sarà la soddisfazione per aver finalmente raggiunto l’obiettivo. Ci sono molti pattern da imparare: googlate, studiate, applicate e ripetete.

Opinione sull’open source

Non usate progetti open source a meno che non sappiate come duplicare tali features da soli. Gli sviluppatori iOS si affidano ai progetti open source per il networking, l’animazione e l’UI. Spesso, tuttavia, gli esordienti si limitano a scaricare ed implementare. È diventato tutto così facile, tanto che in molti non impareranno mai nulla veramente. Ed è un problema.

Immaginate di dover compiere un task semplice. Dovete importare un’enorme libreria. È come aprire una lattina di Coca-Cola con un coltellino svizzero: non ne avete bisogno e diventa ingombrante.

Se non sapete come ottenere quegli effetti e quelle features, studiate. Scaricate il progetto, sezionate il codice e capitelo. Se necessario, copiatelo. Per farlo correttamente è necessario conoscere Access Control nonché l’Object Oriented Programming.

Non fraintendetemi, uso continuamente librerie. Ma le uso perché so bene come fare le cose anche senza di loro (e inoltre mi risparmia parecchio tempo).

Vorrei andare in bicicletta senza usare le mani, tuttavia devo spesso rimetterle sul manubrio per cambiare direzione. Ecco, sarebbe come imparare ad andare in bici senza mani quando non si sa ancora andare in bici. Un paradosso.

Mentalità Protocol Oriented

Presumendo che avete familiarità con OOP (Object Oriented Programming), mi piace pensare a come potrebbero essere ottenuti gli stessi features prima con POP (Protocol Oriented Programming). Potreste iniziare con la Parte 1 e la Parte 2 della mia guida.

Capire il ciclo di vita di un’app

È necessario capire le differenze tra VieDidLoad, ViewWillAppear, ViewDidDisappear; sapere perché usiamo la logica networking e perché esiste AppDelegate. Ho pubblicato un video al riguardo su YouTube: The Life Cycle of an App.

Non pensate al server

Se lottate ancora con Swift e iOS, toglietevi dalla mente l’idea di creare server e database. Usate Firebase, un servizio che consente di immagazzinare dati con meno di 10 righe di codice. Se, per ipotesi, la vostra app diventa popolare tra 100 milioni di utenti, potete sempre assumere un developer backend.

Un vecchio, una volta, disse: “Chi insegue due conigli, non prenderà nessuno dei due”. Ovviamente, se vi sentite abbastanza a vostro agio con l’ecosistema iOS, potreste pensare anche di dare una possibilità ad altre aree.

Documentare, documentare, documentare

Spesso dico che imparare le API è come memorizzare vocaboli di un dizionario. Alcuni di voi non sanno neanche dove poter documentare il proprio lavoro. Non c’è bisogno di un sito web: date un’occhiata in giro, condividete su Medium, caricate su GitHub, fate video su YouTube… oppure create qualche file Playground sul vostro computer. Tutti modi per immagazzinare informazioni e anche per aiutare gli altri. Credo nel karma. Per non parlare del fatto che dà una spinta al proprio brand personale e al marketing.

Come chiedere aiuto

Da editore della pagina Facebook iOS Developers (con 30mila followers), credo che possa esserci molto più margine di miglioramento per coloro che chiedono aiuto. Da persona che dà consigli e che chiede aiuto per varie ragioni, voglio condividere con voi il modo in cui ciò dovrebbe avvenire.

Invece di porre immediatamente la domanda, scriviamo una o due righe per presentarci, per dire chi siamo e come abbiamo trovato la persona o il gruppo. In seguito, esponiamo chiaramente qual è il problema e ciò che abbiamo fatto per trovare una risposta o una soluzione. No, non faccio domande come quelle menzionate all’inizio di questo articolo.

Suggerimento bonus. Se voglio che la mia domanda ottenga una risposta esauriente, offriamo una sorta di incentivo, ad esempio dicendo che avrete il piacere di condividere il lavoro della persona che risolve il nostro problema, in modo che possano beneficiarne anche altri.

Ma, prima di chiedere, Google Google Google. Rimarrete sorpresi dalla quantità di informazioni disponibili su un problema specifico.

Non affidatevi ai tutorial

Spesso cerchiamo dei tutor per essere guidati e per ottenere aiuto. È come tentare di rompere una roccia con un uovo: presto capirete che non è il metodo migliore.

Dobbiamo capire da soli e, se continuiamo ad appoggiarci ai tutorial, si perde la capacità di cogliere veramente un concetto. Cioè, è cosa buona e giusta leggere i miei articoli 🙌🏼 ma se avete intenzione di diventare sviluppatori iOS indipendenti, andate dritti alla documentazione. Cercate di leggere le guide sulle API fornite da Apple. Sfidate voi stessi.

A volte potreste aver bisogno di leggere e rileggere. A dire la verità, personalmente ho letto l’intera documentazione Apple almeno tre volte e memorizzato tutti gli esempi. Leggere un manuale è un’abilità appresa.

I tutorial sono confezionati in modo che gli studenti possano capire facilmente, ma non coprono tutta la materia. Leggere tutorial non è una cosa negativa, io stesso lo faccio, tuttavia bisogna essere disposti ad aggrottare la fronte e scegliere la strada più difficile. Lo dico contro i miei interessi di blogger.

***

Bob Lee è l’autore di questo articolo.

Articolo originale:How to Become an iOS Developer, Bob?

NO COMMENTS

LEAVE A REPLY