Foto di Clément H su Unsplash

In un precedente articolo ho provato a descrivere quali ritengo siano le sfide che deve affrontare chi scrive codice a livello professionale. In questo articolo invece vorrei proporre un possibile approccio entrando nel concreto e dando qualche spunto utile.

Il ciclo di sviluppo

Innanzitutto, per semplificare i passi successivi, è buona pratica suddividere il progetto a cui si sta lavorando in piccole attività progressive, individuandole anche poche per volta ma facendo attenzione a dare priorità a quelle che danno maggiore valore al prodotto. Ogni attività sarà quindi affrontata seguendo un ciclo di sviluppo che ho diviso in cinque fasi ma che può essere personalizzato a secondo della situazione.

L’intero ciclo deve terminare in un periodo di tempo breve - dalla mezza giornata ai due giorni per intenderci - quindi scomponi il lavoro in attività che puoi verosimilmente terminare in questo arco temporale.

1. Individua l’obiettivo

Nella prima fase ti devi assicurare di avere chiaro l’obiettivo che ti porterà a concludere l’attività; in questa fase puoi eventualmente rivedere i requisiti e dialogare con il committente per assicurarti che il tuo lavoro soddisfi le sue necessità.

2. Progetta

Non c’è bisogno di spendere ore e ore nella progettazione (il tempo può variare anche a seconda della complessità dell’attività che devi affrontare) ma può essere molto utile farsi un’idea di cosa andrai a costruire, dei dati che maneggerai e di come organizzare il codice.

3. Sviluppa perché funzioni

Ora facciamo l’indispensabile per fare in modo che l’obiettivo sia raggiunto dalla prospettiva dell’utente. Non significa che bisogna ignorare del tutto le performance e la chiarezza del codice, ma è il caso di concentrarsi principalmente sul raggiungere l’obiettivo sapendo che poi ci sarà un momento dedicato per sistemare il codice dove necessario.

4. Ottimizza

Dato che a questo punto funziona tutto prenditi un momento per verificare che non ci siano punti deboli a livello di performance: potresti aver ripetuto involontariamente più volte lo stesso ciclo di dati oppure potrebbero esserci dei rallentamenti nel rendering delle informazioni quando la loro mole inizia ad essere elevata. Correggi quindi quello che può essere reso più performante e applica qualche tecnica di ottimizzazione se e dove necessario (lazy loading, paginazione, virtual scroll, ecc…). Ovviamente al termine di questa fase devi assicurarti che funzioni ancora tutto correttamente.

5. Documenta

Il lavoro potrebbe quasi considerarsi terminato, ma è il momento di mettersi nei panni di un collega o, se preferite, di noi stessi tra qualche mese. Prendendo in mano il codice risulta tutto chiaro fin dalla prima lettura? Oppure ci sono alcuni punti che potrebbero trarre in inganno o risultare criptici? Quando il codice inizia ad essere stabile (funziona e non deve essere ulteriormente modificato) è il momento migliore per correggere i nomi di variabili, classi e funzioni che non sono sufficientemente chiari (magari inizialmente pensavamo che una funzione avesse uno scopo ma ora ci accorgiamo che per necessità è un po’ cambiata: quale nome esprime meglio cosa fa ora la funzione?). Possiamo suddividere meglio i compiti separando una funzione in tante altre o creando altre classi più specifiche. Infine possiamo aggiungere commenti nei passaggi più complessi e documentare funzioni e classi (per esempio con JSDoc).

Bonus

Concludo con qualche ulteriore spunto a corredo delle idee già descritte.

bonus 1: feedback e retrospettiva

Alla fine di ogni attività, se ne hai occasione, mostra il lavoro a chi te lo ha commissionato e verifica se hai raggiunto l’obiettivo. In questa fase puoi prenderti anche qualche minuto per analizzare il tuo lavoro verificando cosa è andato bene e cosa invece è andato storto; le buone pratiche andranno sostenute e rinforzate mentre i problemi e gli ostacoli possono essere di lezione per il futuro.

bonus 2: i test automatici

Come già accennato, tempo permettendo, i test automatici permettono di individuare più facilmente i bug, le incongruenze e le regressioni. Si possono preparare tanti tipi di test (unit, integration, end to end, …) prima o dopo lo sviluppo, ma è necessario che tutte le persone coinvolte ne riconoscano il valore o rischierà di essere tempo buttato. A meno che tu non sia un libero professionista che porta avanti il lavoro dall’inizio alla fine in totale autonomia, è necessario che la pratica dei test sia metabolizzata e accolta dai tuoi colleghi e probabilmente anche dai tuoi superiori.

bonus 3: abbraccia il cambiamento

Suonerà un po’ filosofico ma bisogna accettare il fatto che tutto cambia, in continuazione. Il software è per sua natura in continuo mutamento (ed è anche uno dei suoi grandi vantaggi) per cui non pretendere di scrivere codice che non cambierà mai più, considera sempre che i requisiti potrebbero cambiare e quello che stai facendo un domani potrebbe non essere più utile.

bonus 4: il dialogo

Davanti ad un tempo limitato dobbiamo limitare anche la qualità del lavoro. Tuttavia le scadenze, le risorse e più in generale l’organizzazione del lavoro sono elementi fluidi nel lungo periodo che, pur essendo normalmente in mano ad altre persone, possono comunque essere influenzati dall’esperienza e dal dialogo. Il dialogo è uno degli aspetti più complessi da gestire, sopratutto per un informatico, ma è fondamentale per una crescita professionale. Dimostrando di saper rispettare i limiti temporali si crea il terreno adatto per aprire un confronto: davanti ad un lavoro fatto con una certa cura è possibile che il tuo committente accetti di concederti più tempo ma potrà funzionare solo se prima ti sarai guadagnato la sua fiducia.