Pochi principi, tanti vantaggi

17 apr 2015 22:28

_Logo In questo periodo, tra le altre cose, sto lavorando al refactoring di codice molto vecchio ed è quasi imbarazzante vedere uno dopo l’altro i tipici errori descritti in letteratura come anti-qualcosa. Sarebbe un ottimo esercizio per nuovi programmatori, se non fosse necessario lavorare in fretta e a colpo sicuro.

Quello che serve infatti per raggiungere in breve tempo un obiettivo, in questo caso facilitare la manutenzione ai fini di migliorare le prestazioni e facilitare il code coverage, è il cosiddetto senso del codice. Una qualità mistica che si acquisisce con anni di esperienza ed una particolare passione per i misteri.

Per quale diavolo di motivo qualcosa è ripetuto in mille modi e in cento posti diversi? Perché per ottenere un risultato già calcolato altrove è richiesto un numero di dipendenze sproporzionato ma proporzionale al numero di linee del metodo? E’ ovvio, e dico ovvio scuotendo la testa, che vi saranno motivi profondi e misteriosi che sicuramente non è il caso di ignorare….

Il bad code ereditato dal passato si fa oggi pesante e molto presente: modificare qualcosa è diventato complesso e risolvere problematiche non banali, come memory leak o il deterioramento delle prestazioni, è un processo rischioso e lungo. Ed è difficile spiegare ad altri che per un certo intervento non si parla di giorni ma di settimane.

Per fortuna la conoscenza approfondita del dominio dell’applicazione permette di non esitare troppo, fortuna che non tutti quelli che devono affrontare del legacy code hanno. Certamente, oggi posso dire che l’utilizzo in passato di pochi principi avrebbe fatto oggi la differenza.

Durante il refactoring, mi sono accorto che per ottenere un ottimo risultato è stato sufficiente applicare ripetutamente pochi principi della programmazione object oriented.

Per prima cosa bisogna suddividere tutto per competenze: progetti, classi, metodi. Poi si può fare i fini lasciando ad ogni elemento un unico scopo. Individuare quali sono le dipendenze tra i vari elementi è invece un lavoro che va applicato nel giusto momento e senza troppo esagerare, soprattutto all’inizio.

Ad esempio, basta raggruppare tutte le dipendenze nel costruttore di una classe e trasformare tali dipendenze in astrazioni. Tali astrazioni devo esporre solo il necessari . Non solo le classi saranno più semplici e chiare, ma spesso molto codice inutile verrà eliminato: perché duplicato o perché non necessario.

Il consiglio è quindi quello di investite del tempo per imparare e comprendere appieno alcuni principi base dello sviluppo, a partire dai principi SOLID: non solo se siete programmatori o sviluppatori che dir si voglia, ma anche se siete team leader o project manager. In quest’ultimo caso non serve conosce un particolare linguaggio o l’ultimo fantastico framework. E’ prima di tutto una questione di ordine e comprensibilità: il codice deve poter essere letto come se fosse una pagina di un libro.

Durante alcuni interventi Uncle Bob chiedeva ai presenti se avessero mai scritto del bad code che aveva poi creato dei problemi. A chi confessava di sì chiedeva laconico: “e allora perché l’avete scritto?”.

Beh, questo è un altro mistero… Anche se la risposta può essere semplice: perché si è smesso di fare refactoring, quel sano refactoring continuativo che mantiene alto il livello di qualità del prodotto.

Tag: SOLID, Refactoring