{"id":35398,"date":"2026-03-03T14:31:48","date_gmt":"2026-03-03T13:31:48","guid":{"rendered":"https:\/\/www.codemotion.com\/magazine\/?p=35398"},"modified":"2026-03-04T13:12:23","modified_gmt":"2026-03-04T12:12:23","slug":"lingegneria-del-possibile-oltre-il-dogma-delle-best-practice","status":"publish","type":"post","link":"https:\/\/www.codemotion.com\/magazine\/it\/carriere-tech\/lingegneria-del-possibile-oltre-il-dogma-delle-best-practice\/","title":{"rendered":"L’Ingegneria del possibile: Oltre il dogma delle “Best Practice”"},"content":{"rendered":"\n
Quando affrontiamo un problema di programmazione, sentiamo spesso frasi rassicuranti quanto limitanti:<\/p>\n\n\n
\"Questo \u00e8 gi\u00e0 stato risolto da [inserire nome guru qui], basta seguire le best practice.\"<\/span><\/code><\/span>Code language:<\/span> JSON \/ JSON with Comments<\/span> (<\/span>json<\/span>)<\/span><\/small><\/pre>\n\n\n
Da un lato, queste parole dovrebbero tranquillizzarmi: il mio problema \u00e8 gi\u00e0 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.<\/p>\n\n\n\n
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 \u00e8 nel caos, se il debito tecnico ci soffoca o se il cliente \u00e8 furioso, la colpa \u00e8 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?<\/p>\n\n\n\n
Per parafrasare il ragionier Ugo Fantozzi:<\/p>\n\n\n
\"Dopo tre mesi di letture maledette, Fantozzi vide la verit\u00e0 e si turb\u00f2 leggermente, o meglio, si incazz\u00f2 come una bestia. Ma allora mi han sempre preso per il culo!\"<\/span><\/code><\/span>Code language:<\/span> JSON \/ JSON with Comments<\/span> (<\/span>json<\/span>)<\/span><\/small><\/pre>\n\n\n
Non si tratta di sminuire i giganti dell’IT, ma di capire che loro descrivono l’eccellenza in condizioni ideali. La nostra missione, invece, \u00e8 l’ingegneria del possibile. Un Senior non \u00e8 colui che sopravvive al fango, ma colui che progetta il modo di bonificare il terreno, un passo alla volta.<\/p>\n\n\n\n
Il miraggio del “Greenfield” e la strategia nel “Brownfield”<\/h2>\n\n\n\n
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\u00e0 \u00e8 pi\u00f9 unico che raro. Meme come<\/p>\n\n\n
\"Deve essere pronto per ieri\"<\/span><\/code><\/span>Code language:<\/span> JSON \/ JSON with Comments<\/span> (<\/span>json<\/span>)<\/span><\/small><\/pre>\n\n\n
non sono solo battute, sono i confini del nostro campo da gioco. La realt\u00e0 della maggior parte di noi \u00e8 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.<\/p>\n\n\n\n
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\u00e9 “nessuno sa cosa succede se cancelli quella colonna”. La seniority qui non \u00e8 rassegnazione, \u00e8 strategia. Dire “il problema \u00e8 risolto” citando un libro \u00e8 come suggerire il laser a un chirurgo sotto i bombardamenti. Il vero professionista sa che l’obiettivo non \u00e8 solo salvare il paziente oggi, ma migliorare le condizioni dell’ospedale da campo affinch\u00e9 domani l’intervento sia pi\u00f9 semplice.<\/p>\n\n\n\n
La tassa sulla complessit\u00e0<\/h2>\n\n\n\n
Il Test Driven Development \u00e8 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\u00e9 \u00e8 cambiato il funzionamento interno del programma, che rimane consistente, ma il mock no.<\/p>\n\n\n\n
Il rischio \u00e8 un codice “testabile”, ma illeggibile. Per i junior questa piramide di astrazioni \u00e8 spesso motivo di orgoglio: “Wow, che architettura fantastica!”. Per un Senior, invece, c’\u00e8 la consapevolezza amara che chi ha scritto quel codice potrebbe aver gi\u00e0 lasciato l’azienda prima che sia necessario passare le notti in produzione a debuggare un bug incomprensibile. \u00c8 il momento della fuga: il codice \u00e8 stato scritto per accrescere il CV, non per essere mantenuto.<\/p>\n\n\n\n<\/figure>\n\n\n\n
E il Clean Code? L’ossessione per le funzioni di tre righe pu\u00f2 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:<\/p>\n\n\n
La speranza qui risiede nella qualit\u00e0 come efficienza: 50 righe di codice sequenziale sono spesso pi\u00f9 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\u00e9 funzioni.<\/p>\n\n\n\n
Continuous Delivery vs. Ufficio Compliance<\/h2>\n\n\n\n
Dave Farley ci insegna che dovremmo rilasciare in produzione pi\u00f9 volte al giorno. Il deployment non dovrebbe essere un evento, ma un “non-evento” privo di stress. Bellissimo. Poi per\u00f2 provate a dirlo all’ufficio compliance di una banca o al responsabile della sicurezza di un’azienda che gestisce dati sensibili.<\/p>\n\n\n
Ah, vorreste fare deployment ogni ora? \nEcco il lasciapassare A-38 da compilare per ogni rilascio, firmato dal responsabile di reparto, dal CISO e dal DPO.\nServe un piano di rollback validato e la finestra di deployment \u00e8 il marted\u00ec tra le 2 e le 4 di notte.<\/code><\/span><\/pre>\n\n\n
Il Guru ti dir\u00e0 che \u00e8 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\u00ec sera cancellando i dati di diecimila clienti. La seniority strategica accetta questi muri di gomma e cerca di automatizzare ci\u00f2 che \u00e8 possibile, senza ignorare i vincoli della realt\u00e0 burocratica.<\/p>\n\n\n\n
Microservizi: Scalabilit\u00e0 vs Semplicit\u00e0<\/h2>\n\n\n\n
“I monoliti non scalano”. E cos\u00ec spezziamo sistemi efficienti in 47 microservizi che comunicano tra loro con sette protocolli diversi (o chiamate dirette al database altrui perch\u00e9 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”.<\/p>\n\n\n\n
Il debugging diventa una caccia al tesoro tra log desincronizzati su pi\u00f9 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\u00e0 immane per risolvere un problema che non avevamo, solo perch\u00e9 “Netflix lo fa cos\u00ec”. Tu non sei Netflix; non hai 10.000 ingegneri. La seniority \u00e8 saper dire “no” alla complessit\u00e0 inutile.<\/p>\n\n\n\n
Agile: da manifesto a burocrazia<\/h2>\n\n\n
\"Individui e interazioni pi\u00f9 dei processi e degli strumenti\"<\/span>.<\/code><\/span>Code language:<\/span> JavaScript<\/span> (<\/span>javascript<\/span>)<\/span><\/small><\/pre>\n\n\n
Poi ti ritrovi in daily standup di 45 minuti dove nessuno inizia a parlare, e quando tocca a te inventi una “supercazzola” perch\u00e9 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\u00e0 in un’industria di certificazioni, Scrum Master, SAFe e KPI. L’agilit\u00e0 si trasforma in burocrazia con un vocabolario diverso. La speranza \u00e8 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\u00e0 \u00e8 un’attitudine, non un board su Jira.<\/p>\n\n\n\n
Gestire il debito: Oltre la sindrome del TODO<\/h2>\n\n\n
\"Lascia il codice migliore di come l'hai trovato\"<\/span><\/code><\/span>Code language:<\/span> JSON \/ JSON with Comments<\/span> (<\/span>json<\/span>)<\/span><\/small><\/pre>\n\n\n
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 \u00e8 una sconfitta se lo si fa con metodo. Non basta scrivere un TODO che nessuno legger\u00e0 mai.<\/p>\n\n\n\n
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\u00e9 tutti sono al mare (e tu ci andrai a settembre). Questa \u00e8 la differenza tra un Senior e un dilettante: il primo contrae un debito consapevole, il secondo crea un disastro involontario.<\/p>\n\n\n\n<\/figure>\n\n\n\n
La Metafora del Tavernello: Scope vs Qualit\u00e0<\/h2>\n\n\n\n
Una volta mi hanno detto:<\/p>\n\n\n
\"Se hai 3 euro in tasca compri un Tavernello, non un Barolo.\"<\/span><\/code><\/span>Code language:<\/span> JSON \/ JSON with Comments<\/span> (<\/span>json<\/span>)<\/span><\/small><\/pre>\n\n\n
\u00c8 un’analogia potente. Nell’IT usare un prodotto che non copre in modo corretto i requisiti pu\u00f2 causare problemi pi\u00f9 grandi di quelli che si avrebbero comperando un prodotto di fascia alta. Il vero compromesso non deve riguardare la qualit\u00e0 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.<\/p>\n\n\n\n
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 \u00e8 fatta, rischio zero e impatto bassissimo. Se lo fanno i Guru dei microservizi, forse non \u00e8 cos\u00ec sbagliato. Quel codice “brutto” spesso sopravvive anni generando valore, mentre il codice “bello” iper-ingegnerizzato viene riscritto dopo sei mesi perch\u00e9 nessuno sa come toccarlo.<\/p>\n\n\n\n
I guru vendono libri, noi vendiamo soluzioni<\/h2>\n\n\n\n
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\u00f9 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.<\/p>\n\n\n\n
Dobbiamo creare soluzioni basate sul reale. I Guru indicano la vetta, ma siamo noi che dobbiamo tracciare il sentiero tra i rovi. L’eccellenza \u00e8 fornire la massima qualit\u00e0 possibile entro i vincoli dati, non lamentarsi dei vincoli stessi.<\/p>\n\n\n\n<\/figure>\n\n\n\n
Ma quindi siamo vecchi o senior?<\/h2>\n\n\n\n
La differenza \u00e8 che il vecchio ha smesso di imparare, il senior ha smesso di essere un fanatico. Il senior ha studiato le regole cos\u00ec bene da sapere esattamente quando infrangerle per salvare il progetto, trasformando quella deroga in un atto consapevole di ingegneria.<\/p>\n\n\n\n
Ha imparato che “dipende” \u00e8 la risposta pi\u00f9 onesta. Che il codice perfetto \u00e8 nemico del codice funzionante. Che consegnare il 90% in tempo \u00e8 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\u00f2 una ragione.<\/p>\n\n\n\n
Ci vediamo in trincea. Sguazziamo nel fango, teniamo in piedi monoliti e costruiamo ponti. Perch\u00e9 alla fine, la colpa non \u00e8 dei Guru che ci hanno fatto credere nella perfezione, ma nostra se abbiamo smesso di cercare l’eccellenza possibile per rincorrere quella immaginaria.<\/p>\n\n\n\n
![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/03\/19-ingannobestpractice-2-nanobanana.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/03\/19-ingannobestpractice-3-nanobanana.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/www.codemotion.com\/magazine\/wp-content\/uploads\/2026\/03\/19-ingannobestpractice-it-infografica.png\")
<\/figure>\n\n\n\n