3 cose che ho imparato ad un anno dalla laurea

È già passato un anno dal giorno della mia laurea in informatica e automazione. 

Inizialmente, subito dopo la laurea, la mia idea era di partecipare ad un master in data science  organizzato dalla facoltà di ingegneria. Questo master sarebbe dovuto partire pochi giorni dopo la mia laurea invece, a causa del mancato raggiungimento del numero minimo di partecipanti, la data di inizio è stata continuamente posticipata. Quindi, dopo il secondo rinvio a metà Dicembre, ho deciso di lasciar perdere il master e di buttarmi nel mondo del lavoro.

Così ho iniziato a lavorare per una piccola azienda che aveva in programma di realizzare una start-up innovativa per realizzare un software in grado di automatizzare alcune operazioni svolte in ambito cloud.  

Lavorare alla scrittura di un software da zero era veramente entusiasmante, avevo una chiara visione di come dovesse essere strutturato tutto il progetto non avevo vincoli sulle tecnologie da utilizzare o su come impostare il progetto. 

Il problema però era che nessuno in azienda aveva mai avuto un’esperienza diretta nello sviluppo di un software complesso. 
Di conseguenza procedevamo nello sviluppo andando un po' a naso utilizzando le poche nozioni di gestione di progetti apprese all'università senza seguire una metodologia di sviluppo ben precisa.
Quindi più passava il tempo e più sentivo che nonostante ci impegnassimo il 110% ogni giorno, la mancanza di una figura che fosse in grado di definire una road-map per il progetto ci impediva di proseguire al meglio nello sviluppo.

Così, quando il professore con cui avevo fatto la tesi mi ha scritto una mail informandomi circa la possibilità di seguire un corso presso un azienda specializzata nello sviluppo software ho colto la palla al balzo e ho deciso di provare a vedere come poteva essere lavorare in un azienda più strutturata.
In questa azienda ho prima seguito un corso introduttivo di circa 3 settimane sullo sviluppo tramite i linguaggi PHP e Angular e poi ho svolto un ulteriore tirocinio di 4 mesi. Ad oggi mi trovo ancora in questa azienda lavorando come apprendista.

Questa è stata in breve la mia esperienza durante l'anno immediatamente successivo alla laurea e voglio riportare quelle che per me sono state le lezioni più importanti che ho appreso nel corso di questi mesi.

1 - L’importanza dei design pattern e del naming

Quando si lavora ad un progetto in un team è assolutamente fondamentale impostare correttamente la struttura del codice. 
All'università ti spiegano cosa sono e a cosa servono i design pattern ma fino a che non li ho visti applicati ad un progetto concreto (e soprattutto complesso) non riuscivo ad apprezzarne veramente il valore.
Applicando correttamente i design pattern diventa quasi immediato riuscire a capire come fixare eventuali bug o come implementare nuove funzioni anche senza dover conoscere tutto il codice. 

Sempre in questo ambito ho capito l’importanza del naming delle classi e delle variabili. All'università di questo punto se ne parla pochissimo, ti dicono che i nomi devono essere informativi (e non il solito “pippo”) ma tutto qua. Invece perdere qualche minuto per pensare al naming è fondamentale. 
Lavorando ho visto classi e variabili per cui semplicemente leggendo il nome riuscivo a capire come funzionasse un intero blocco di codice senza la necessità di avere nemmeno un commento. 
Un altro aspetto molto sottovalutato è la definizione di uno stile unico per la scrittura del codice. Ad esempio:

• lasciare sempre uno spazio prima dell'apertura delle parentesi 
• non eccedere 120 caratteri per ogni riga 
• mantenere uno standard unico per l'indentazione del codice
• non lasciare doppie righe vuote
• definire le costanti utilizzando caratteri in maiuscolo

In questo modo anche quando allo stesso progetto lavorano più sviluppatori contemporaneamente è possibile garantire che il codice scritto sia sempre coerente aumentandone notevolmente la leggibilità. 

2 - L’importanza dei test

Un’altro fattore che all’università viene liquidato con: “i test sono importanti e vanno fatti” in realtà è un fattore fondamentale per la buona riuscita di un progetto. 

Diverse volte mi è capitato di dover fixare un bug in un punto modificando una classe e introducendo bug  o "effetti collaterali" da altre parti del progetto in cui la classe era utilizzata. Se non fosse stato per i test che fallivano non avrei mai individuato questi problemi. 
Ma l'utilità dei test non si limita solo a prevenire eventuali bugs. Spesso, durante la scrittura dei test, ragionando in un secondo momento sul codice scritto in precedenza mi rendo conto di possibili migliorie e rifattorizzazioni che posso fare per incrementare la leggibilità e l'eleganza del codice. 

Uno strumento come Jenkins in grado di far girare tutti i test automaticamente ad ogni push sul repository è veramente una manna dal cielo per garantire un elevata qualità del codice.

3 - Le code review

Prima di lavorare non ne avevo mai sentito parlare e invece sono uno strumento che definire fondamentale è poco. 

In parole povere, una volta che lo sviluppo di una feature è terminato, prima di essere aggiunta alla branch master del progetto uno sviluppatore (diverso da quello che ha scritto il codice) analizza tutte le modifiche effettuate lasciando commenti e suggerimenti. 

Inizialmente pensavo che le code review fossero solo un modo per controllare che le modifiche effettuate fossero "valide".

Invece sono uno strumento molto più utile, tipicamente il lavoro dello sviluppatore è molto solitario: ti danno un problema da risolvere e te devi risolverlo da solo. 

Lavorando da soli uno si porta dietro il proprio bagaglio di idee e convinzioni che pensa possano essere valide nella risoluzione di un determinato problema. 
La code review invece è un modo per confrontarsi con una persona diversa, per vedere il suo punto di vista e per mettere in dubbio il codice che è stato scritto. 

Tramite questa procedura si “perde” parecchio tempo ma il codice che ne viene fuori è di qualità nettamente superiore. 

Inoltre, nel mio caso specifico, un altro vantaggio delle code review è stato che poichè non conoscevo bene PHP tramite le correzioni che mi venivano proposte ogni volta sono riuscito a imparare da chi è molto più preparato di me migliorando in breve tempo le mie conoscenze. 

(bonus): Comunque si tiri la coperta è corta

Questa penso che sia la lezione fondamentale che mi hanno lasciato 5 anni di ingegneria e che poi ho ritrovato anche nel mondo del lavoro. 

Infatti avendo avuto la fortuna di poter vivere la realtà della formazione di una start-up e quella di un azienda con alcuni anni di esperienza sono stato in grado di poter fare i dovuti confronti e mi sono reso conto che non esiste un modo unico e perfetto per affrontare un problema. 

Nella start-up la massima priorità era necessità di avere un prototipo pronto da mostrare ad eventuali investitori e quindi c’era la costante ansia di aggiungere nuove feature a discapito di una maggir strutturazione dell'architettura del codice. 

In un azienda invece già affermata e con un prodotto già sul mercato le dinamiche sono profondamente diverse e viene maggiorente premiata la manutenibilità del codice nel lungo periodo rispetto alla velocità di rilascio di nuove feature.

Questa è stata la mia esperienza condensata in 3 punti e sono sicuro che ognuno ne abbia avuta una differente. Se vuoi parlarmene lasciami pure un commento qui sotto :)