Sull’estetica del codice

Ci sono molti programmatori, decisamente troppi, che nel 2017 ancora pensano che l’eleganza nel codice sia solo un vezzo, un virtuosismo superfluo, una ricerca di una pulizia fine a sé stessa. Sono stati spesi fiumi di parole su questo tema ed esistono una marea di libri sull’argomento, alcuni dei quali sorvolano sulla correlazione tra estetica e debito tecnico. Questi promuovono gli stessi principi di pulizia, ordine, eleganza e armonia nel codice che rimangono validi da mezzo secolo come fossero semplici metodologie pratiche per scrivere buon codice che non ti esploderà in faccia al primo corner case.

Viene però omessa appunto la premessa fondamentale: un codice manutenibile è un codice elegante e un codice elegante è l’unico codice che merita di essere scritto, perché qualsiasi alternativa porta, prima o dopo ad una crisi di debito tecnico. Tutti abbiamo passato serate/weekend a ridosso delle deadline a fare accrocchi indicibili e lì esiste una scusante, ma non esiste la scusante il giorno dopo per non smontare l’accrocchio e rifarlo. E allo stesso modo tutti avranno sperimentato l’azienda o il project manager che non lasciano i tempi tecnici per lavorare bene, ma questi sono vittima dello stesso errore, ovvero credere che la qualità estetica del codice non sia un valore quantificabile. Lo è e l’overhead portato dal cattivo codice te lo ritrovi quando sfori le deadline.

Questa mancanza di cultura estetica è a mio parere aggravata dalla narrativa intorno alle good practice, al clean code, al less is more: troppa pratica e poca teoria. Si stanno dando sardine invece di insegnare a pescare i merluzzi. Metodologie sempre più convolute per strutturare codice, dati e processi, liste infinite di good practice legate al linguaggio/framework di turno e quant’altro.

Tutte queste cose sono inutili se manca la consapevolezza del problema di fondo: il codice è forma e sostanza contemporaneamente e se la forma del codice non si armonizza alla sostanza, nascono i problemi. Colmare la discrepanza tra forma e sostanza richiede energie mentali da parte di chi sta lavorando al codice, da parte di chi farà manutenzione, da parte di chi lo userà come libreria se è il caso e, in casi estremi, da parte dell’utente finale che potrebbe ritrovarsi un UX sub ottimale a causa della struttura interna di un software.

Spiegaglielo al PM che sfori la deadline. Spiegaglielo al senior che lavora da 15 anni su Java e ha 12 certificazioni diverse su Spring che si fa un weekend al mese in ufficio. Spiegaglielo allo studente che vede i suoi compagni finire i progetti 3 settimane prima della scadenza.

Che la qualità del codice non sia di massima importanza, sia nella sua componente estetica sia in quella funzionale, è una bugia che ci raccontiamo per farci andare bene il fatto che lavoriamo in un posto di merda, o è una giustificazione per non continuare a fare sforzi extra per studiare cose nuove e scrivere codice migliore. Più facile sopportare giorno dopo giorno, portare a casa lo stipendio e alienarsi da ciò che si crea, invece di ambire a qualcosa di più.

Non tutti ricercano il Tao, per molti programmare è un lavoro come un altro ed è comprensibile che non puntino a migliorarsi ma solo a portare a casa il pane. E ci sta, se non si ha la passione, meglio scrivere COBOL o roba enterprise, che almeno ti pagano bene. Go for it.

Ma tante volte le persone che gettano la spugna e vanno con la corrente son persone che la passione l’hanno avuta ma sono state soffocate dalle contingenze, da ambienti lavorativi tossici e in ultimo, dalla mancanza di strumenti culturali con cui difendere la propria passione davanti agli incessanti assalti dell’imperativo capitalista: produrre, vendere, guadagnare.

Noi programmatori, tutti, possiamo ambire ad una remunerazione sopra la media facendo un lavoro che ci piace, ci diverte e ci soddisfa. Sono molto poche le categorie professionali che possono fare la stessa affermazione. Però nella pratica questo succede solo ad una frazione di noi e succede per una questione culturale, che diventa questione economica e in ultimo politica.

Il diritto ad avere spazio per scrivere buon codice è una questione fondamentalmente politica ed è imperativo etico di ogni programmatore. Questione politica perché i programmatori in Italia sono una categoria di sfruttati che ha stipendi troppo bassi in confronto ai colleghi esteri e questione politica perché un settore composto principalmente da programmatori che non migliorano come potrebbero è un settore destinato ad ingrossarsi numericamente mantenendo legioni di manovali sottopagati e inefficienti. E chi ha il potenziale e si trova soffocato se ne va all’estero.

Imperativo etico perché si è collettivamente responsabile della situazione in essere nella propria azienda e nel mercato del lavoro. La lotta sindacale è morta, la contrattazione collettiva è moribonda e la coscienza di classe nell’IT non è manco mai nata. Quindi la presa di responsabilità individuale per migliorare la propria condizione e quella altrui deve assumere forme nuove, inaspettate e non comprensibili dal sistema che ha creato le condizioni attuali.

L’equazione tra il cambiamento del mercato del lavoro e la coltivazione della forma (e non solo della sostanza) nel codice che si scrive è tutto fuorché semplice, ma forse è intuitiva per chi questo percorso l’ha già fatto o lo sta facendo. Il percorso di liberazione salariale dettato da un’incessamente miglioramento delle proprie capacità può avvenire solo se si lavora in un ambiente in cui una frazione maggioritaria del proprio tempo è speso a creare qualcosa che ci migliori. Rattoppare in fretta codice malscritto non è sicuramente il modo giusto. Se lo si fa ogni giorno della propria vita per decenni, ci si ritrova quarantenni con un CV vergognoso, lo stress sopra i capelli e lo stipendio di un lustrascarpe.

Il tempo è la risorsa più rara che esista nella vita di una persona con delle ambizioni e programmare bene è un’ambizione che, come tutte le arti, ne richiede una quantità immensa. Sottostare alla volontà altrui che ci impone di scrivere in fretta, di scrivere il minimo necessario per mettere in produzione e mettere pezze quando tutto si rompe è un torto alla bellezza e alla nostra dimensione di esseri umani.

Spero che questo post arrivi sopratutto agli studenti, perché la maggior parte delle persone che programma male da 15 anni probabilmente arriverà a metà del post e lo bollerà come il berciare di un giovane arrogante e ingenuo. Sono gli studenti che ancora non lavorano a dover far propria la nozione che la continua e instancabile ricerca estetica nella programmazione è una delle forze fondamentali che crea i programmatori bravi ed è in sé stessa la ricompensa dello sforzo speso ad inseguirla.

Non scrivete mai codice per i vostri professori o per i vostri datori di lavoro e men che meno per i clienti: scrivete codice per voi stessi per migliorarvi, per i vostri pari più capaci per farvi insegnare e per i vostri pari meno bravi per insegnare a loro quello che avete imparato. Quello che consegnate a mezzanotte prima della deadline di un progetto d’esame rimarrà su un server in qualche sgabuzzino dell’università per qualche anno e poi sparirà. Lo stesso per la delivery della nuova feature richiesta urgentissimamente dal cliente. Qualche anno e il cliente fallirà, cambierà software o qualcuno cancellerà la vostra implementazione. Son solo bit. Non pesano niente. Non sono importanti.

Quello che vi rimane è nella vostra testa e nella vostra persona, è nelle opportunità che vi crea e nei discorsi che farete con persone con la vostra stessa passione che, in ultimo, vi lasceranno ancora di più.

Il codice è troppo importante per scriverlo male.

Ringrazio Walter Cazzola per avermi insegnato a vergognarmi sempre e comunque del mio codice e Stefano Baghino per avermi insegnato l’umiltà e la disciplina (mai abbastanza).