Eccoti di fronte a un articolo che non mostrerà blocchi di codice, ma che ti aiuterà a diventare uno sviluppatore migliore! Non lo sto dicendo con leggerezza, i tre principi che andremo ad analizzare in questo articolo sono fondamentali per poter svolgere correttamente il tuo lavoro.

Continua a leggere se non mi credi 😉

All’interno di skillsAndMore ci impegnamo veramente molto a fornire del materiale per gli sviluppatori che desiderano migliorare le proprie conoscenze. Assumere un atteggiamento di questo tipo è molto importante perché una delle bellezze del web è che si tratta di un ambiente in continua evoluzione.

Questo significa che anche mentre stai dormendo, guardando un film o passando dei bei momenti con la tua famiglia c’è qualcuno che sta lavorando per migliorare e velocizzare il nostro lavoro!

Ora non voglio che tu ti senta in colpa e neanche sconfortato da questa realtà, ma è un dato di fatto. Possiamo svegliarci la mattina e scoprire che su GitHub qualcuno ha rilasciato una nuova libreria JavaScript, una nuova configurazione per Vagrant o addirittura un nuovo approccio alla programmazione.

Questi non sono aspetti negativi ma, anzi, è tutto il buono che il web ha da offrire.

Eppure, indipendentemente dal linguaggio di programmazione, indipendentemente dalla piattaforma o dal dispositivo esistono dei principi sui quali si dovrebbe basare il lavoro di qualsiasi sviluppatore.

Ecco perché mi sono deciso a scrivere un articolo di questo genere, conoscendo questi principi sarai in grado di applicarli al tuo lavoro, di riconoscerli nel lavoro degli altri e di sfruttarli al meglio!

Sto facendo un errore?

Io penso proprio di no! Fin troppo spesso ci troviamo a rincorrere il framework, la libreria o il nuovo modo in cui si creano le nostre applicazioni. Eppure non è tutto qua. Con i principi che discuteremo oggi voglio aiutarti a piantare le basi che qualsiasi bravo sviluppatore deve seguire.

Sei pronto a conoscerli?

Allora andiamo subito a incontrare il primo principio che inizierà a rivoluzionarti la vita!

PS: stavo per dimenticare, questi principi sono stati descritti in inglese perché ti sarà molto più facile trovarli per la rete grazie ai loro acronimi. Non aver paura che il loro significato è molto semplice 🙂

Don’t Repeat Yourself (DRY)

Non esiste un corso all’interno di skillsAndMore dove non abbiamo fatto riferimento a questo principio fondamentale: ripetersi è un’inutile perdita di tempo!

Questo è il concetto che sta alla base del principio DRY, ma cosa nasconde al suo interno? Che significa che non dobbiamo ripeterci?

Devi forse smettere di usare il pulsante Invio?

Ebbene non è assolutamente di questo che stiamo parlando, il DRY non significa esplicitamente evitare di ripetere la pressione su determinati tasti della tastiera e non deve essere confuso con le sintassi di linguaggio di programmazione come Ruby (giusto per dirne uno), dove i punti e virgola e le parentesi sono stati abbandonati.

Questo non significa applicare un principio DRY!

Per capirlo al meglio dobbiamo fare un passo indietro e valutare il nostro lavoro, che cosa realizziamo? Applicazioni, giusto?

Queste applicazioni possono assumere diverse forme e attraversare diversi gradi di complessità. Abbiamo la possibilità di creare una semplice calcolatrice come quella di creare un’applicazione web che assimila dati da diversi siti web per analizzarli in un’unica interfaccia.

Per esempio, puoi trovare una calcolatrice online per fare semplici calcoli matematici, come un sito ben più complesso che prende il nome di Google Analytics che ci permette di raccogliere moltissime informazioni su siti web e di eseguire complessi calcoli per valutare l’impatto del nostro sito.

Puoi immaginare quanto sia complesso un sito del genere?

Ebbene questo è proprio un ottimo caso che ci permette di comprendere al meglio il principio DRY che, piccola nota storica, è un termine apparso per la prima volta all’interno del libro The Pragmatic Programmer, anche se un po’ vecchiotto, mette in luce aspetti fondamentali che permettono di diventare sviluppatori migliori tra cui anche il principio DRY.

Pensiamo un attimo alla complessità che può avere un’applicazione web del calibro di Google Analytics.

Deve avere la possibilità di collegarsi a un sito, un sistema di tracciamento delle informazioni, diverse schermate per eseguire studi approfonditi sul traffico ottenuto, la possibilità di far loggare gli utenti, la capacità di creare grafici… Insomma gli aspetti che dobbiamo tenere in considerazione sono veramente molti, ma cosa c’entra tutto questo con il DRY?

Ebbene facciamo un passo indietro e osserviamo il comportamento di questa applicazione un po’ più da lontano. Dove vengono salvate tutte le informazioni sulle visite, il login degli utenti, il comportamento dei visitatori ecc?

All’interno di un database.

Questo significa che ogni volta che la nostra applicazione avrà bisogno di qualche informazione dovrà connettersi a un database, in PHP si potrebbe scrivere qualcosa del genere:

$db = mysqli_connect('localhost','user','password','database') or die('Errori nella connessione al database.');

Se la nostra applicazione non è sviluppata correttamente, dovremmo ripetere questa operazione ogni volta che ci troviamo di fronte alla necessità di recuperare le informazioni dal database.

Andando ad analizzare dei concetti più teorici possiamo definire:

Il principio DRY dichiara che tutti i piccoli pezzi di conoscenza devono verificarsi soltanto una volta all’interno del sistema.

Quindi tornando all’esempio precedente, la conoscenza rappresentata dalla connessione al database deve essere presente soltanto una volta all’interno del nostro codice, infatti questo è l’unico modo per non ripetersi.

Sono sicuro però che stai pensando che è più facile a dirsi che a farsi, non è vero?

Molto spesso noi sviluppatori, che rappresentiamo l’ultimo anello nella catena decisionale per un progetto, siamo costretti a inserire veloci correzioni distruggendo la struttura dell’applicazione che stiamo creando perché le richieste fatte all’ultimo minuto sono molte. Vuoi sapere la verità?

Non è assolutamente colpa tua!

La colpa è di chi sta gestendo il progetto. Di chi dovrebbe aver pianificato con il cliente il lavoro da svolgere e che si dovrebbe essere assicurato che tutti i dettagli fossero delineati. Se questi aspetti mancano e il cliente non viene guidato alla comprensione dei tempi necessari allo sviluppatore per realizzare le singole modifiche, allora possiamo dimenticarci di rispettare il principio DRY.

Allo stesso tempo, non sempre è colpa del cliente.

Essere in grado di applicare questo principio significa saper progettare sulla carta, prima ancora di scrivere una singola riga di codice. Questo è  fondamentale perché conoscere la struttura di un progetto ti permetterà di sapere quali componenti sono necessari e con questi potrai identificare dove potranno accadere il maggior numero di ripetizioni.

Prima di passare al prossimo principio ci sono un paio di esempi che vorrei condividere con te.

Il primo è presente all’interno del mio CMS preferito, WordPress. Come ti dovresti immaginare questa piattaforma deve connettersi moltissime volte al database per svolgere azioni come far accedere un utente che sta facendo il login, mostrare la lista degli ultimi articoli o far commentare uno sconosciuto. Insomma come descritto anche all’interno del nostro corso, il database rappresenta la memoria di questo CMS.

Però WordPress applica molto bene il DRY.

Infatti per poterci connettere al database, tutto quello che dobbiamo fare è inserire le corrette informazioni all’interno del file wp-config.php e il gioco è fatto. Tutte le operazioni che verranno svolte con il database faranno riferimento ai dati inseriti al suo interno e la cosa ancor più bella risulta in un gran salvataggio di tempo!

Ovviamente la logica DRY di questo CMS si rispecchia anche nelle varie funzioni che mette a disposizione dato che sono state create diverse classi PHP che permettono di interrogare il database senza dover ripetere le query con le quali selezioniamo le varie tabelle.

Abbiamo una classe che ci permette di configurare come desideriamo una query in grado di prendere gli articoli (WP_Query), una che ci permette di andare a interagire con tutti i commenti collezionati dal nostro CMS (WP_Comment_Query), un’altra che ci permette di andare a richiamare tutte le informazioni salvate per i nostri utenti (WP_User_Query) e via dicendo…

Insomma, se hai voglia di ispezionare il codice WordPress scoprirai molti punti in cui il principio DRY viene applicato correttamente. Adesso però è giunto il momento di prendere un esempio completamente diverso!

Prima di passare al prossimo principio voglio fare un esempio ancora più semplice e probabilmente allineato con le tue conoscenze.

Immagino che ti sia capitato di creare un sito web, giusto? Durante la sua pianificazione con il designer incaricato avrete delineato alcuni elementi i cui stili si ripetono lungo tutta l’esperienza dei visitatori. Elementi come i bottoni, i colori di sfondo, la posizione delle immagini ecc…

Penso che tu abbia riconosciuto a chi appartiene questa styleguide, vero?

Se ti fosse rimasto il dubbio questo è il documento creato per Medium usato per dare le prime forme alla sua applicazione. Come puoi vedere tu stesso qua sopra possiamo trovare molte caratteristiche che definiscono l’intera esperienza che un visitatore può avere all’interno del sito web. Per prima cosa abbiamo un delineato arrotondamento degli angoli, tutti i bottoni utilizzano lo stesso stile e questo fa subito pensare alla creazione di una classe CSS dedicata.

Successivamente, parlando sempre di bottoni, abbiamo una serie di colori differenti che descrivono i diversi stati che possono avere e anche in questo caso avere una classe CSS da poter utilizzare per distinguere i diversi bottoni non farà altro che evitarci di dover scrivere tutte le volte le proprietà background-color.

Potrei andare avanti ancora per molto, portando in esame molti altri esempi in cui il principio DRY dimostra la sua utilità, ma non lo farò.

Personalmente spero di aver messo in luce l’importanza di conoscere, rispettare e applicare (dove possibile) questo principio. Adesso dobbiamo passare a quello successivo che presenta un nome un po’ scorbutico, ma ti assicuro che è altrettanto importante!

Keep it Simple Stupid (KISS)

Spero tu non ti sia offeso per il nome di questo principio, ma il Mantieni semplice, Stupido! è veramente potente e può essere applicato in moltissime occasioni in cui la nostra mente sta facendo dei pensieri fin troppo complicati.

Facciamo un esempio tornando indietro di qualche anno.

Siamo alla fine del XIX secolo e molti fisici si stavano picchiando per riuscire a descrivere come la gravità e il magnetismo erano in grado di disturbare le ottiche sulle lunghe distanze. Erano talmente concentrati ad analizzare il problema che hanno addirittura dichiarato un nuovo elemento: l’etere.

Ovviamente la creazione di questo elemento, che non aveva alcun fondamento scientifico, faceva acqua da tutte le parti perché negli anni seguenti sono stati rilevati nuovi dati che hanno richiesto la modifica di questa teoria.

Fintanto che non arrivò un impiegato dell’ufficio brevetti di Berna e dimostrò a tutti che si sbagliavano. Con il suo approccio out-of-the-box fece capire che i fondamenti del pensiero di questi scienziati era completamente sbagliato. Non era necessario creare un nuovo elemento, dovevano semplicemente accettare che il tempo non era un valore costante e che poteva modificarsi a seconda della velocità e della distanza.

Con questo piccolo, ma rivoluzionario, esempio che ti ho fatto vorrei farti capire quanto sia essenziale per dei creativi essere in grado di poter pensare evitando di restare legati a delle strutture che crediamo vere, soltanto perché abbiamo sempre fatto così.

Facciamo un altro esempio.

Un cliente ci chiede di poter importare i suoi file Excel all’interno della propria applicazione per poterne utilizzare i dati contenuti al suo interno.

Come probabilmente sarai a conoscenza, Excel è un’applicazione della suite Microsoft Office e il suo formato .xlsx è proprietario e quindi non è facile da comprendere e manipolare da parte di altre applicazioni. Inoltre dobbiamo tenere presente che con Excel possiamo fare molte altre operazioni che non sono direttamente utili nella conoscenza del dato, come la possibilità di applicare formule matematiche e la creazione di grafici.

Però l’unico interesse del nostro cliente sono i dati contenuti al suo interno.

Quindi, al posto di andare a studiare come Excel salva questi dati all’interno del suo file proprietario, scoprire come farlo leggere alla nostra applicazione e trovare un modo per inserire i dati all’interno della nostra applicazione, si potrebbe risolvere tutto con un semplice .csv!

In fin dei conti questa applicazione è in grado di esportare file con command-separated-value e per i computer è incredibilmente semplice leggere questa struttura di dati. In fin dei conti servono soltanto una manciata di righe di codice e il gioco è fatto.

Questo è un approccio che dovrebbe essere applicato in qualsiasi lavoro, in fin dei conti perché dobbiamo reinventare la ruota quando parliamo con un cliente?

Per mantenere attivo il cervello alla ricerca di soluzioni semplici, ma efficaci, ti consiglio di avere bene a mente i prossimi tre concetti ogni volta che ti trovi a valutare come trasformare le richieste di un cliente in soluzioni da sviluppare:

• è sbilanciata nei contronti della difficoltà di sviluppo e degli effettivi benefici?
• ha una stretta dipendenza nei confronti di un’altra funzionalità?
• rischia di crescere molto in complessità nella vita del progetto?

Con queste tre semplicissime domande potrai assicurarti di fare sempre la scelta migliore. In fin dei conti se un cliente mi chiede un sistema di login per pubblicare articoli e mantenere il suo sito aggiornato, io non faccio altro che pensare a WordPress. Non tanto perché questa è la mia piattaforma preferita, ma piuttosto perché mi salva dalla necessità di creare un sistema di login e di sviluppare le strutture necessarie.

In tutta onestà, sono anche convinto che il codice di questa piattaforma sarà infinitamente più sicuro di quello che potrò realizzare io.

Nel nostro lavoro questa è la caratteristica importante: essere in grado di soddisfare i nostri clienti e al tempo stesso di portare a casa un buon risultato nel minor tempo possibile. E questo è possibile raggiungerlo applicando il principio KISS!

You Ain’t Gonna Need It (YAGNI)

Ed eccoci all’ultimo e anche forse più riassuntivo principio che voglio trattare all’interno di questo articolo. Dall’acronimo complicato (almeno io non riesco mai a ricordarmelo) si denota un significato incredibilmente semplice che significa: Non ti servirà a niente.

Con questo principio possiamo prendere in esame le richieste del nostro cliente, il budget e il tempo che abbiamo a disposizione e decidere veramente se metterci a lavorare su una determinata feature o meno.

Facciamo un esempio pratico che sicuramente può chiarirci le idee.

Siamo stati contattati da un cliente che ha richiesto lo sviluppo di un’applicazione web che possa connettersi al database per recuperare determinate informazioni.

Conoscendo il budget e la tipologia di cliente sappiamo già che l’applicazione che stiamo sviluppando verrà ospitata su un economico hosting condiviso.

Siamo sicuri al 99,9% che su questi hosting il tipo di database con il quale si troverà a lavorare la nostra applicazione sarà MySQL quindi, al posto di scrivere una classe in grado di connettersi a tutti i database presenti sulla faccia della terra, pensiamo solamente a scrivere il codice in grado di connettersi a questo!

Il ragionamento di quest’ultimo principio è molto semplice in fin dei conti.

È vero che il nostro intento è fare il miglior lavoro per i nostri clienti, così magari torneranno da noi nel futuro ecc… Ma la cosa più importante che dobbiamo valutare durante lo svolgimento di un lavoro è se quello che stiamo facendo copre le spese.

Anche io all’inizio della mia carriera mi sono trovato molte volte a creare delle soluzioni ingegnose che il cliente neanche aveva chiesto, vuoi sapere che cosa è successo? Le opzioni sono sempre state due:

• o il cliente non apprezzava/capiva il lavoro svolto (cosa che causava non poche frustrazioni);
• oppure semplicemente non piaceva e io avevo perso ore di sviluppo inutilmente.

In entrambi i casi non c’è mai stato neanche un cliente che si è proposto di pagare il lavoro extra che avevo svolto.

Non voglio assolutamente dire che tutti i clienti si comporteranno così anche con te, ma è una possibilità. E anche se unica, devi tenere bene a mente che noi siamo qua per lavorare e non per sprecare il tempo che abbiamo a disposizione.

Se per esempio non avessi investito il mio tempo nella creazione di soluzioni ingegnose, avrei potuto utilizzarlo per cercare nuovi clienti e velocizzare la mia crescita professionale.

Quindi, riassumendo questo principio, se ti trovi di fronte a un brief di un progetto concordato con il cliente, non utilizzare il tempo che ti avanza per aggiungere altre caratteristiche ma piuttosto migliora il codice che hai realizzato e consegna soltanto quanto è stato chiesto.

Se un domani il cliente ti contatterà nuovamente e avrà bisogno di una feature che non era stata concordata durante le vostre riunoini, questo è il momento corretto per richiedere un altro pagamento.

Conclusioni

I  principi che abbiamo visto in questo articolo sono incredibilmente importanti per chiunque si ritenga uno sviluppatore. In certi casi ci aiuteranno a salvare del tempo ricordandoci che se la ruota è la stessa da migliaia di anni un motivo ci sarà 😉

In altri casi questi principi ci aiutano a impostare il nostro lavoro in modo professionale tenendo sempre a mente che il lavoro che dobbiamo svolgere è quello che abbiamo concordato con il cliente, senza extra inutili.

Non vorrei passare come una persona cattiva dopo aver scritto queste parole, ma parlando in tutta onestà sono convinto che se oggi abbiamo come clienti delle persone che desiderano mettere bocca su tutto e che si ritengono anche in grado di migliorare il nostro lavoro la colpa è anche nostra.

Mi sto aprendo a un nuovo concetto che si merita un articolo dedicato, quindi prima di lasciarti voglio ricordarti i principi che abbiamo conosciuto in questo articolo:

• DRY – visto che scriviamo codice per realizzare i nostri lavori, cerca di ripeterti il meno possibile e sfrutta le strutture del linguaggio in modo intelligente.
• KISS – il cliente non ha sempre ragione e talvolta la feature che richiede è semplicemente rischiosa da implementare, in questi casi è meglio trovare l’incontro migliore tra semplicità e funzionalità.
• YAGNI – spesso le cose che sviluppiamo non servono e questo ci fa perdere del tempo, meglio se ti impegni a migliorare la qualità del codice o a cercare nuovi clienti perché per le modifiche puoi sempre emettere una nuova fattura.

Ecco, questi sono i concetti che desidero tu porti a casa.

Non si parla di scienza e tantomento di programmazione, ma piuttosto di buone pratiche che se applicate nel nostro lavoro miglioreranno sicuramente la nostra quotidianità.

Se hai opinioni o idee a riguardo non ti scordare di utilizzare la sezione dei commenti presente qua sotto per portare avanti la conversazione 😉