Quando affrontiamo un problema di programmazione, sentiamo spesso frasi rassicuranti quanto limitanti:
"Questo è già stato risolto da [inserire nome guru qui], basta seguire le best practice."Code language: JSON / JSON with Comments (json)Da un lato, queste parole dovrebbero tranquillizzarmi: il mio problema è già stato decodificato e risolto da menti illuminate. Dall’altro, mi fanno sentire inadeguato, come se fossi un eretico che non riuscisse a vedere la “luce” della soluzione perfetta, ripetendo errori ormai superati da centinaia di anni di storia informatica.
Frasi del genere ci inducono a credere che l’informatica sia una scienza esatta, come la matematica, dove 2+2 fa sempre 4. Suggeriscono che se il progetto è nel caos, se il debito tecnico ci soffoca o se il cliente è furioso, la colpa è esclusivamente nostra: non abbiamo applicato correttamente “La Ricetta”. Ma dopo anni di tastiere consumate, inizio a farmi una domanda scomoda: e se le ricette dei Guru fossero una stella polare, utile per navigare, ma pericolosa se scambiata per il porto di destinazione?
Per parafrasare il ragionier Ugo Fantozzi:
"Dopo tre mesi di letture maledette, Fantozzi vide la verità e si turbò leggermente, o meglio, si incazzò come una bestia. Ma allora mi han sempre preso per il culo!"Code language: JSON / JSON with Comments (json)Non si tratta di sminuire i giganti dell’IT, ma di capire che loro descrivono l’eccellenza in condizioni ideali. La nostra missione, invece, è l’ingegneria del possibile. Un Senior non è colui che sopravvive al fango, ma colui che progetta il modo di bonificare il terreno, un passo alla volta.
Il miraggio del “Greenfield” e la strategia nel “Brownfield”
I “libri sacri”, da Extreme Programming a Clean Code, fioriscono nel “Greenfield”: praterie verdi dove si costruisce da zero, con team di alto livello, budget elastici e cultura del fallimento. Kent Beck, Martin Fowler, Dave Farley e Robert C. Martin (Uncle Bob) sono menti brillanti, ma le loro teorie assumono un contesto che nella realtà è più unico che raro. Meme come
"Deve essere pronto per ieri"Code language: JSON / JSON with Comments (json)non sono solo battute, sono i confini del nostro campo da gioco. La realtà della maggior parte di noi è il Brownfield: monoliti stratificati dal 1995, database con campi nominati campo1, campo2, campo3 (con un manuale che spiega il significato di ognuno) e documentazione “nella testa” di ex colleghi.
Ricordo un progetto in cui un rivolo di sangue mi usciva dagli occhi ogni volta che dovevo capire cosa stava succedendo nel database. Spesso lavoriamo su sistemi che non possono essere toccati perché “nessuno sa cosa succede se cancelli quella colonna”. La seniority qui non è rassegnazione, è strategia. Dire “il problema è risolto” citando un libro è come suggerire il laser a un chirurgo sotto i bombardamenti. Il vero professionista sa che l’obiettivo non è solo salvare il paziente oggi, ma migliorare le condizioni dell’ospedale da campo affinché domani l’intervento sia più semplice.
La tassa sulla complessità
Il Test Driven Development è uno strumento potente, ma se usato acriticamente genera architetture contorte, sature di interfacce inutili usate da una sola classe e mock fragili che si rompono solo perché è cambiato il funzionamento interno del programma, che rimane consistente, ma il mock no.
Il rischio è un codice “testabile”, ma illeggibile. Per i junior questa piramide di astrazioni è spesso motivo di orgoglio: “Wow, che architettura fantastica!”. Per un Senior, invece, c’è la consapevolezza amara che chi ha scritto quel codice potrebbe aver già lasciato l’azienda prima che sia necessario passare le notti in produzione a debuggare un bug incomprensibile. È il momento della fuga: il codice è stato scritto per accrescere il CV, non per essere mantenuto.
E il Clean Code? L’ossessione per le funzioni di tre righe può diventare un incubo. Ho lavorato su progetti dove per capire un invio dovevi aprire 18 file diversi costituiti per il 60% da commenti ereditati come questo preso dalla codebase del core di Linux:
FIXME: this function is never used, whyCode language: JavaScript (javascript)La speranza qui risiede nella qualità come efficienza: 50 righe di codice sequenziale sono spesso più manutenibili di un puzzle di micro-funzioni astratte sparse ovunque, ognuna con un nome lungo quanto una frase e un test che mocka tre livelli di dipendenze. Il cliente non paga per l’eleganza, paga perché funzioni.
Continuous Delivery vs. Ufficio Compliance
Dave Farley ci insegna che dovremmo rilasciare in produzione più volte al giorno. Il deployment non dovrebbe essere un evento, ma un “non-evento” privo di stress. Bellissimo. Poi però provate a dirlo all’ufficio compliance di una banca o al responsabile della sicurezza di un’azienda che gestisce dati sensibili.
Ah, vorreste fare deployment ogni ora?
Ecco il lasciapassare A-38 da compilare per ogni rilascio, firmato dal responsabile di reparto, dal CISO e dal DPO.
Serve un piano di rollback validato e la finestra di deployment è il martedì tra le 2 e le 4 di notte.Il Guru ti dirà che è un problema culturale. Ma lo sviluppatore non ha il potere di riscrivere le leggi bancarie europee o di convincere l’auditor che “i nostri test coprono tutto”. Quelle regole sono nate dal sangue di disastri reali: qualcuno ha fatto un deploy di venerdì sera cancellando i dati di diecimila clienti. La seniority strategica accetta questi muri di gomma e cerca di automatizzare ciò che è possibile, senza ignorare i vincoli della realtà burocratica.
Microservizi: Scalabilità vs Semplicità
“I monoliti non scalano”. E così spezziamo sistemi efficienti in 47 microservizi che comunicano tra loro con sette protocolli diversi (o chiamate dirette al database altrui perché non c’era tempo per l’API). Il grafico delle dipendenze sembra il disegno di mio figlio all’asilo quando “gli piaceva fare i cerchi”.
Il debugging diventa una caccia al tesoro tra log desincronizzati su più container, dove tail e grep sono considerati roba per poveracci. Ma nella mia azienda abbiamo 100 utenti concorrenti: CENTO. Una mole di traffico che anche un monolite in Visual Basic 6 gestirebbe senza sudare. Abbiamo creato una complessità immane per risolvere un problema che non avevamo, solo perché “Netflix lo fa così”. Tu non sei Netflix; non hai 10.000 ingegneri. La seniority è saper dire “no” alla complessità inutile.
Agile: da manifesto a burocrazia
"Individui e interazioni più dei processi e degli strumenti".Code language: JavaScript (javascript)Poi ti ritrovi in daily standup di 45 minuti dove nessuno inizia a parlare, e quando tocca a te inventi una “supercazzola” perché ti vergogni a dire che hai perso otto ore di vita per una codepage della tabella DB non allineata. Abbiamo trasformato un manifesto di libertà in un’industria di certificazioni, Scrum Master, SAFe e KPI.
L’agilità si trasforma in burocrazia con un vocabolario diverso. La speranza è che l’essenza dell’Agile risieda nel team che si parla davvero, proteggendosi dalle “feature ad personam” dettate da manager che chiedono stime basate sul nulla (o sul nome della feature stessa). L’agilità è un’attitudine, non un board su Jira.
Gestire il debito: Oltre la sindrome del TODO
"Lascia il codice migliore di come l'hai trovato"Code language: JSON / JSON with Comments (json)Una regola d’oro, ma che non deve diventare una giustificazione per refactoring infiniti che fanno slittare le deadline. Il Senior sa che aggiungere un “brutto if” non è una sconfitta se lo si fa con metodo. Non basta scrivere un TODO che nessuno leggerà mai.
Gestire il debito significa negoziarlo: si inserisce la pezza per rispettare la deadline, si apre un ticket di refactoring e si concorda che il “prestito” tecnico va restituito. Magari ad agosto, quando hai tempo per ragionare perché tutti sono al mare (e tu ci andrai a settembre). Questa è la differenza tra un Senior e un dilettante: il primo contrae un debito consapevole, il secondo crea un disastro involontario.
La Metafora del Tavernello: Scope vs Qualità
Una volta mi hanno detto:
"Se hai 3 euro in tasca compri un Tavernello, non un Barolo."Code language: JSON / JSON with Comments (json)È un’analogia potente. Nell’IT usare un prodotto che non copre in modo corretto i requisiti può causare problemi più grandi di quelli che si avrebbero comperando un prodotto di fascia alta. Il vero compromesso non deve riguardare la qualità intrinseca (il codice deve essere corretto, sicuro e testato), ma lo scope (cosa facciamo). Se hai poco budget, non cucinare un pranzo di nozze scadente: prepara un’ottima pasta al pomodoro. Semplifica i requisiti, non la cura con cui scrivi le righe di codice.
Ricordo un video dove Luca Mezzalira parlava di DAZN: per cambiare l’anno nel footer dei siti, editano a mano 4 file. Soluzione sporca? Forse. Ma in 5 minuti è fatta, rischio zero e impatto bassissimo. Se lo fanno i Guru dei microservizi, forse non è così sbagliato. Quel codice “brutto” spesso sopravvive anni generando valore, mentre il codice “bello” iper-ingegnerizzato viene riscritto dopo sei mesi perché nessuno sa come toccarlo.
I guru vendono libri, noi vendiamo soluzioni
I Guru sono chef stellati che comprano ingredienti di prima scelta. Noi siamo i cuochi che devono sfamare 200 persone in un’ora. Se provi a replicare la ricetta del Tiramisù di Iginio Massari senza avere il tempo per i savoiardi fatti in casa, finirai con le persone che se ne vanno a casa scocciate per l’attesa. Usa i biscotti del supermercato e concentrati su una crema decente.
Dobbiamo creare soluzioni basate sul reale. I Guru indicano la vetta, ma siamo noi che dobbiamo tracciare il sentiero tra i rovi. L’eccellenza è fornire la massima qualità possibile entro i vincoli dati, non lamentarsi dei vincoli stessi.
Ma quindi siamo vecchi o senior?
La differenza è che il vecchio ha smesso di imparare, il senior ha smesso di essere un fanatico. Il senior ha studiato le regole così bene da sapere esattamente quando infrangerle per salvare il progetto, trasformando quella deroga in un atto consapevole di ingegneria.
Ha imparato che “dipende” è la risposta più onesta. Che il codice perfetto è nemico del codice funzionante. Che consegnare il 90% in tempo è meglio del 100% in ritardo. E se questo significa passare per uno che “vive nella comfort zone” agli occhi di chi fa vibe coding con l’ultimo framework pubblicizzato su X: me ne farò una ragione.
Ci vediamo in trincea. Sguazziamo nel fango, teniamo in piedi monoliti e costruiamo ponti. Perché alla fine, la colpa non è dei Guru che ci hanno fatto credere nella perfezione, ma nostra se abbiamo smesso di cercare l’eccellenza possibile per rincorrere quella immaginaria.
