Contents
Articolo di: L’Ottimista Cinico, Sviluppatore C# Senior (che ha visto cose che voi umani…)
Ciao a tutti i miei colleghi schiavi del public static void Main(string[] args),
Oggi voglio parlarvi di un argomento che mi scalda il cuore più di un ciclo while(true) in un thread senza sleep: il Codice Legacy.
Ah, il Codice Legacy. Non è solo codice vecchio. È una forma d’arte, un monumento alla fretta, alla deadline di ieri e, diciamocelo, alla pura e semplice negligenza creativa. Nella nostra gloriosa azienda di sviluppo, il Codice Legacy non è un problema; è la nostra cultura aziendale, il nostro patrimonio immateriale più prezioso.
La Promessa della Rifattorizzazione
Ogni sei mesi, come un orologio cosmico in disfacimento, arriva la “Grande Rifattorizzazione”. Il Product Owner (che capisce di codice quanto io capisco di uncinetto) entra nella stanza con gli occhi lucidi e annuncia: “Quest’anno, finalmente, riscriveremo quel modulo! Lo porteremo in .NET 8, useremo i nuovi Design Pattern, sarà bello, pulito, agile!”.
Noi, i veterani, alziamo un sopracciglio e ci scambiamo un’occhiata che dice: Ancora con questa storia?.
La rifattorizzazione è la carota appesa davanti al nostro naso, il sogno bagnato di ogni sviluppatore C#. Ci fanno credere che un giorno potremo vivere in un mondo di Unit Test al 100%, di Dependency Injection impeccabile e di classi con un solo, sacro, scopo. Ma, come sappiamo tutti, la rifattorizzazione è l’equivalente software della dieta del lunedì: inizia con grande fervore, finisce con un pacchetto di patatine fritte e una corsa sfrenata per mettere una pezza al bug dell’ultimo minuto.
Il Mio Migliore Amico, il Commento “TODO: Fix Later”
Lavorare con il Codice Legacy è un po’ come essere un archeologo ubriaco. Scavi tra strati di codice scritto da gente che o è andata in pensione, o è in esilio autoimposto in una capanna senza WiFi.
La cosa più bella? I commenti. Ah, i commenti!
// TODO: Fix later. This is bad, but it works for now. (scritto 7 anni fa)// Non toccare questo, non so perché funzioni, ma lo fa.// Secondo me qui non ci passa
Il mio preferito è sempre // WTF?. Un commento che racchiude in tre lettere la disperazione, la rassegnazione e un grido di aiuto universale che trascende il tempo e le versioni di Visual Studio. Ogni volta che incontro uno di questi, mi sento in una conversazione intima e millenaria con un collega sconosciuto e angosciato.
La Cerimonia del Patch Rapido
Il vero valore di uno sviluppatore C# in un’azienda come la nostra non sta nella sua capacità di scrivere codice pulito e moderno. No. Il vero valore è la sua maestria nel fare una “Patch Rapida” su codice che dovrebbe essere sepolto sotto metri di cemento.
Il processo è sacro:
- Ricevi la Chiamata: Il Capo Progetto (sempre isterico) ti dice che la funzionalità critica ha smesso di funzionare in produzione.
- Immergiti: Apri la soluzione, che impiega 15 minuti solo per caricare. Cerchi il codice incriminato, di solito una classe chiamata
UtilityHelperServiceFactoryManagerBase. - Applica il Cerotto: Invece di rifattorizzare le 400 righe di spaghetti code, tu, l’eroe, aggiungi una riga:
if (value == "null") value = string.Empty;. Questo perché a nessuno è venuto in mente di fare una semplice validazione a monte. - Il Committ: Fai un commit con il messaggio conciso:
"Fix: Bug in Prod". Nessun dettaglio, nessuna spiegazione. La paura che qualcuno possa porre domande è un deterrente sufficiente. - Il Test: Chiedi al QA di testare. Loro lo fanno. Funziona. Nessuno si chiede perché ha smesso di funzionare e perché ora funziona. L’importante è che il problema sia sparito dal loro backlog.
E così, abbiamo reso il Codice Legacy ancora più Legacy, stratificandolo con un altro sottile velo di incomprensibile ingegneria inversa. Ma hey, l’abbiamo fatto in fretta. E l’efficienza, in questa azienda, è il sacro Graal.
Conclusione: La Vita è un Try-Catch
Quindi, la prossima volta che vi sentite giù di morale per il codice che siete costretti a mantenere, ricordate: non state scrivendo codice, state scrivendo storia! Una storia piena di compromessi, deadline irrealistiche e quella costante, meravigliosa sensazione di déjà vu quando debuggate lo stesso errore per la quarta volta in tre anni.
Tanto, la grande rifattorizzazione arriverà… un giorno. E quando succederà, non cambierà nulla. Sarà solo l’inizio del Nuovo Codice Legacy.
Ora scusatemi, devo inserire un try-catch (Exception ex) generico nel punto in cui il vecchio codice incontra il nuovo. Non si sa mai cosa potrebbe succedere, e onestamente, non voglio saperlo.
Buon debugging a tutti!