Qualità del codice: un dovere a beneficio di tutti

Perchè è importante scrivere del codice di qualità? Abbiamo intervistato Fabio Flebus, nostro Team Leader e abbiamo affrontato una tematica a lui molto cara, la qualità del codice (da buon sviluppatore..). Una riflessione per migliorare il lavoro di squadra e facilitare il lavoro del singolo.

Partiamo da un concetto di base, che cosa vuol dire scrivere un buon codice?

Fin dall’università siamo abituati a pensare in termini di complessità (the Big O), partendo quindi dal presupposto che un software veloce, sviluppato con algoritmi complessi si basi sicuramente su un ottimo codice. Nel nostro ambito, quello dello sviluppo e-commerce, c’è un altro aspetto fondamentale che va tenuto in considerazione, oltre quello delle performance, ed è quello della manutenibilità. Quindi per rispondere alla domanda, per me un buon codice è quello facile da leggere, modificare, aggiornare e correggere.

E come si fa quindi a scrivere del buon codice?

Le regole per scrivere un buon codice sono conosciute da qualsiasi sviluppatore, quello su cui voglio però concentrare l’attenzione è l’importanza di tenere presente le regole quando si lavora in team. Per noi scrivere un buon codice è una sorta di dovere morale, perché la qualità del codice interessa tutti all’interno di un’azienda, chi in maniera diretta chi in maniera, indiretta, d’altronde ne va della buona riuscita di un progetto.

Ci spieghi meglio cosa intendi?

Si parla di linguaggi di programmazione. Sappiamo tutti che con il termine linguaggio si intendono una serie di convenzioni che ci permettono di comunicare. Si può pensare che il programmatore col suo codice stia comunicando alla macchina le istruzioni da eseguire, in realtà non è così, il programmatore quando scrive il codice sta parlando anche ai colleghi e a sé stesso, nel momento in cui si troverà eventualmente a lavorare di nuovo sul quel progetto specifico. Insomma, quello che intendo dire è che il rapporto tra codice scritto e codice letto è infinitamente a favore di quest’ultimo. Lo leggiamo più e più volte, per sistemare i bug, per ricordarci come funziona una parte dell’applicativo, oppure per estrapolare dei pezzi che vogliamo riutilizzare. Diventa quindi immediato capire l’importanza di scrivere un buon codice e l’importanza delle buone pratiche di refactoring, ovvero riguardare quello che si è fatto per sistemarne la “forma”.

Nel concreto quindi, quali sono gli aspetti da considerare nel refactoring?

La cosa più importante (e a volte difficile) da fare durante il refactoring è il naming, dare un nome alle cose (le classi, i metodi, le variabili), infatti un naming corretto e ragionato ci fa capire, e fa capire agli altri, come siamo arrivati a modellare una soluzione. Un altro aspetto che reputo importante dopo tanti anni di esperienza è la semplicità, spesso quella che può apparire come una soluzione “troppo” semplice spesso è la soluzione migliore (NO all’ overengineering).

E i commenti? C’è chi pensa che un buon codice sia un codice “ricco” di commenti…

A mio parere i commenti non sono da prendere in considerazione, almeno non in prima istanza, perché un buon codice si commenta da solo. Avere un codice ricco di commenti non è sinonimo di facile leggibilità. Anzi, i commenti sono spesso ignorati (non per niente l’IDE li mostra con un colore poco evidente, di solito il grigio), non aggiornati o dicono qualcosa di ovvio. E se il commento descrive qualcosa di diverso da quello che effettivamente fa il codice, è ancora peggio dell’assenza di commenti.