Maledetto codice legacy

Pubblicato da Stefano Castelvetri il 05/03/2026

C'è questo momento che prima o poi arriva, nella vita di ogni sviluppatore, in cui l'entusiasmo per un progetto si trasforma in delirio mistico. E la determinazione nel non usare linguaggio sconcio viene messa a dura prova.

Succede quando quel repository che nessuno toccava dal 2014 all'improvviso secerne codice legacy. Non parlo di codice vecchio ma solido, quello che non si tocca perché funziona. Parlo di un groviglio di istruzioni scritte da qualcuno che odiava il genere umano, che magari aveva già dato le ddimissioni, o che forse aveva solo troppa fretta e troppo caffè in circolo. È quel software che sta in piedi solo grazie alla tensione superficiale dei suoi stessi bug.

Mettere le mani in quel disastro è un po' come giocare a Shangai, o Mikado. Ti ricordi gli stecchini di legno colorati? Ecco, il database è lo stecchino blu in fondo, la logica di business è quello giallo incastrato a metà e l'interfaccia utente è una massa informe di stecchini rossi che premono su tutto il resto. Tu sai che dovresti applicare solo una piccola modifica su un campo di inserimento, un fix da niente, ma appena sfiori la tastiera senti un sinistro scricchiolio provenire dal server. Se sposti una virgola in un form, improvvisamente smette di funzionare la logica di fatturazione, come se fossero unite da entanglement quantico. Una fisica che non studiano a ingegneria, ma che impari a tue spese durante il debugging.

La reazione naturale di chiunque abbia un minimo di cervello sarebbe dare fuoco a tutto, fare tabula rasa, cancellare il repository e iniziare riscrivere tutto da capo seguendo dei principi razionali. Ma qui arriva la parte divertente, quella che mette seriamente alla prova la tua pazienza. Provi a chiedere: "Ma cosa dovrebbe fare, esattamente, questo modulo?". Silenzio. Scrollate di spalle. Sguardi imbarazzati. Non esistono specifiche, la documentazione è una leggenda metropolitana e l'unica persona che sapeva come funzionasse si è trasferita tre anni fa a coltivare lavanda in Provenza.

E mentre fissi lo schermo cercando di interpretare variabili chiamate temp1, temp2 e final_final_flag_v2, senti il fiato sul collo della scadenza. Perché ovviamente c'è da consegnare. Ieri. Il business non può aspettare che tu faccia ordine o che renda il mondo un posto migliore con il tuo codice strutturato. Vogliono solo che il pezzetto di legno sia sfilato senza che l'intera struttura crolli.

E allora ti armi di santa pazienza, fai un bel backup e inizi a muoverti con la grazia di un chirurgo. Ogni riga di codice che scrivi è un compromesso, un piccolo pezzo di anima che se ne va in cambio della stabilità del sistema. È un lavoro sporco, frustrante, ma c'è una sorta di perversa soddisfazione nel vedere che, nonostante tutto, quella pila di stecchini rimane immobile mentre ti allontani dalla scrivania.

Bene. Saprai che il cerchio della vita, in questo settore, ha un senso dell'umorismo piuttosto cinico. Tra un paio d'anni, o forse tra sei mesi se siamo sfortunati, arriverà qualcuno che aprirà quel file, leggerà il tuo fix dell'ultimo minuto e inizierà a imprecare contro l'ignoto autore di tale scempio (non avrai firmato quel codice, te ne vergogni troppo). Ti darà del pazzo, dell' incompetente, e si chiederà come sia stato possibile scrivere qualcosa di così fragile. Cercherà persino il tuo nome nei log di git per maledirti degnamente. Ma, se tutto è andato bene, per allora tu sarai già altrove. Magari avrai finalmente seguito l'esempio del tuo predecessore e ti troverai davvero in Provenza, ad ammirare i campi di lavanda che ondeggiano al vento, sorseggiando un vino locale e dimenticando per sempre cosa sia un'eccezione non gestita.

Alla fine è un prezzo da pagare, un male necessario. Una sorta di purgatorio digitale dove ogni sviluppatore professionista prima o poi è destinato a sfilare lo stecchino di qualcun altro, sperando solo che la pila non crolli proprio al suo turno.