Il mestiere più bello del mondo

Il codice è lì che ti aspetta, devi aggiungere una nuova funzione al sistema di catalogazione.

Devi montarla dentro una struttura esistente. Puoi prendere il pezzo di codice e attaccarlo come una palla di fango a tutto il resto del sistema; è una cosa che si può fare; si fa anche quando si è di corsa. Ma oggi hai un po’ più di tempo. Puoi guardare con un minimo di calma in giro, e capire cosa c’è davvero da fare.

Guardi dove devo creare la nuova funzione. Il codice funziona, ma non è recentissimo – ha un anno, più o meno.

Esamini i test che ne verificano il funzionamento; ce ne sono una decina. Sono confusi, esprimono male quello che vogliono fare. Cominci piano a correggerli, a renderli più chiari ed espliciti. Ne aggiungi altri. Ora i test sono chiari. E’ chiaro cosa stai provando – in questo caso, la finestra del programma a cui dovrà essere collegata la nuova funzione. Hai rinforzato le fondamenta su cui lavorare. Ora devi andare sopra, e cominciare a costruire.

Guardi il codice che gestisce la finestra. Non è male, ma ovviamente va rivisto. Va rifattorizzato. Questa è la parte che ti piace del tuo mestiere – stranamente, non aggiungere cose nuove ai sistemi. Rivedere il codice esistente e cercare di capire come potrebbero essere scritti meglio; rendere i programmi diventano più stabili, più flessibili e più facili da comprendere e da modificare.

E’ una sfida intellettuale continua. E’ una via di mezzo fra capire una dimostrazione matematica, e riparare una vecchia motocicletta che dovrebbe partire e non lo fa.

Hai davanti un sistema che fa alcune cose utili, altrimenti non saresti lì a guardarlo; al suo interno è contenuta conoscenza importante – quella che noi chiamiamo conoscenza del dominio applicativo. Questa conoscenza è ben nascosta nel profondo delle righe del codice, in cicli annidati, in classi dai nomi incomprensibili, in righe e righe di codice.

Comincia ad esaminare il sistema. Procedi con calma. Scrivi un test – un programma che verifica un altro programma - prima di fare modifiche. Poi fai un piccolo cambiamento: modifichi il nome di una variabile qui, il nome di un metodo la. Trovi un piccolo pezzo di codice che può essere semplificato; trovi una classe che era nascosta, e che può essere resa esplicita – un concetto che era espresso implicitamente, e che assume vita propria.

Il lavoro è lento, paziente, costante. Non si finisce in un’ora. Neppure in un giorno. Smonti un pezzetto alla volta, sperando di andare nella direzione giusta. Definisci concetti nuovi e li leghi assieme. Poi, lentamente, acquisti forza. I concetti si strutturano in ragionamenti, i ragionamenti in teorie. Il tuo sistema non parla più di oggetti binari, tratta informazioni complesse. Puoi leggere il codice del tuo programma e vedere quello che vuol fare e non semplicemente cosa sta facendo.

Poi, all’improvviso cade un diaframma. Sono momenti particolari. Hai lavorato una settimana, un mese a semplificare e riscrivere il codice, magari mentre facevi altro. Poi rimuovi un frammento, e ti accorgi che una gran parte del tuo sistema si è semplificato. E’ diventato migliore – ti da conforto guardarlo. Lo provi, e funziona perfettamente. E’ la bellezza del codice: riesce ad essere elegante e robusto insieme.

Ti accorgi che è tardi e stai facendo un lavoro che il tuo capo non ti pagherà mai. Sei rimasto solo a tu a guardare il tuo codice. Ma a te non importa. Il codice è codice, e scriverlo e rifattorizzarlo è il mestiere più bello del mondo.