Blog Post

Come programmatori siamo troppo spesso giudicati solamente sulla base delle nostre conoscenze. Nonostante tutto il mondo sostenga che un programmatore non debba imparare a memoria comandi o istruzioni, spesso ai colloqui anche di aziende di grossa portata, si richiede ancora la risoluzione di determinati problemi per mezzo di linguaggi specifici.

Quello che invece mi piace pensare è che un giorno la parola ‘programmatore’ verrà sostituita dalla parola ‘sviluppatore’, così sontuosa alla sua pronuncia. Molto spesso gli sviluppatori basano le loro scelte su poche regole, ma tutte incentrate su principi fondamentali e comuni ad ogni linguaggio. Quello che ho cercato di fare in questo articolo è raccogliere e riassumere quei principi o almeno quelli che io considero fondamentali.

Il commento come arma (a doppio taglio)
Il maggiore problema che porta con sè il commento è che va aggiornato con il funzionamento.
Per fare un esempio concreto, è un po’ come un test automatico: scrivi una logica e progetti un test automatico che utilizzi questa logica, poi va a finire che cambi la logica di partenza e puntualmente il test automatico si rompe.

A questo punto, se non hai impostato una GitHub action che esegua i test ad ogni commit, sei fregato. Non ti accorgi che il test automatico è rotto fino a quando non hai concluso lo sviluppo, magari settimane dopo, e quindi non ricordi più nulla. Il commento è essenziale, ma è utile solo quando è aggiornato. Il consiglio è quello di non commentare le parti di codice che cambiano spesso, ma se una parte di codice viene chiamata spesso e non cambia da mesi, allora può essere un buon punto da cui cominciare.
Però non farti del male commentando qualsiasi cosa.

Code splitting
Come il codice Javascript viene diviso quando viene mandato al browser, anche il codice sorgente deve essere diviso prima che arrivi al team di sviluppo. Mentre il Javascript può essere diviso in blocchi a seconda della pagina a cui appartiene, il codice sorgente deve avere una divisione logica, che purtroppo non sempre è immediata.
Non è necessario categorizzare ogni singolo nella propria singolare cartella, ma non è corretto inserire una classe ben scritta a casaccio all’interno di una cartella del codebase. La giusta via di mezzo direi che è una categorizzazione a 3 livelli. Il cervello umano infatti fatica a ricordarsi il nodo trisnonno in una gerarchia, quindi è meglio mantenere un albero semplice.

Io spesso utilizzo la convezione ‘nomefile.tipofile.ext’, che per come è strutturato, aiuta a ricordare la logica con cui occorre modificare tale file.

Cerca la via di mezzo nella categorizzazione.

Ordine vs Velocità
Certi algoritmi per essere veloci hanno bisogno di utilizzare costrutti e tecniche non sempre immediate da capire. Molto spesso, per esempio, occorre utilizzare gli indici per accedere ad un array e sommarli, incorrendo in fastidiosi e inutili mal di testa, soprattutto quando si rileggono questi codici dopo tanto tempo. A volte però certe ottimizzazioni risultano impercettibili e non necessari in relazione alla mole di lavoro che la routine si presta a svolgere.
Non serve scrivere un algoritmo di ordinamento super ottimizzato, quando gli elementi da ordinare sono quindici. Certo, si perde in prestazioni e velocità computazionale, ma si guadagna in velocità progettuale e soprattutto in leggibilità.

Nomenclatura
A chi non è capitato di leggere un pezzo di codice scritto da altri e trovare variabili a, b, rt, pci, pls o qualche altro strano ed incomprensibile acronimo?
Che fastidio quando accade.

In LH ci è capitato per le mani un codebase dove ricorre molto spesso la parola WES e ancora oggi non sappiamo quale sia il suo significato. Immaginate poi che arrivi qualcuno a cui va spiegato precisamente cosa fa il software e che si sente ripetere WES sei o sette volte in trenta secondi, senza che gli si riesca a spiegare cosa voglia dire.
Riuscire a dare un nome corretto e concreto ad ogni variabile può essere dunque un compito arduo. Io personalmente preferisco avere una variabile un po’ più lunga da leggere, che riempia più caratteri sullo schermo, ma che spieghi esattamente quale sia la sua ragione d’esistenza.

Team Organizzati con i colleghi
Anche se stai lavorando sulla stessa cosa da settimane e sai già esattamente quello che sta facendo lo sviluppatore che tocca il tuo stesso progetto, confrontati con lui prima di mettere le mani sulla tastiera, per capire se ha intenzione di modificare i tuoi stessi file, se vuole introdurre cambiamenti radicali o se vuole fare modifiche che forse tu avresti fatto in un modo diverso. Magari ha bisogno di un consiglio.

Mantieni il dialogo aperto, mandargli il video del podcast che segui sull’Intelligenza artificiale, il web3, la programmazione di embedded device per monitorare il battito cardiaco dei cani. Magari anche lui ha qualche news interessante da condividerti, che potrebbe potenzialmente rivoluzionarti la giornata.

Ogni grande progetto ha sempre bisogno di tante teste.