[{"data":1,"prerenderedAt":648},["ShallowReactive",2],{"has-blog-posts":3,"post-software-non-risolve-caos-organizzativo":4,"related-software-non-risolve-caos-organizzativo":180,"datemod-software-non-risolve-caos-organizzativo":162},true,{"id":5,"title":6,"body":7,"category":161,"date":162,"description":163,"extension":164,"image":165,"meta":166,"navigation":3,"path":167,"published":3,"seo":168,"seoTitle":169,"slug":170,"stem":171,"tags":172,"updated":178,"__hash__":179},"blog/blog/2026-04-14-software-non-risolve-caos-organizzativo.md","Il software non può risolvere un caos organizzativo",{"type":8,"value":9,"toc":145},"minimark",[10,18,21,24,29,35,38,41,45,50,53,56,60,63,66,70,73,77,86,93,97,105,108,112,115,122,125,129,132,136,139,142],[11,12,13,17],"p",{},[14,15,16],"strong",{},"Un cliente aveva centinaia di clienti, ognuno con logiche di prezzo diverse: a peso, a pezzo, con forfait, con sconti storici, con accordi presi a voce negli anni."," Voleva un software che \"automatizzasse tutto\". La digitalizzazione dei processi aziendali senza prima fare ordine produce esattamente questo: un sistema pieno di eccezioni, con decine di logiche di calcolo diverse, che nessuno riesce davvero a spiegare.",[11,19,20],{},"Quel software non era scritto male. Era la trasposizione fedele di un business senza regole chiare.",[11,22,23],{},"Ed è qui il punto: il software codifica quello che già esiste. Se a monte manca ordine, a valle troverai solo una versione più rigida della stessa confusione.",[25,26,28],"h2",{"id":27},"il-software-è-uno-specchio","Il software è uno specchio",[11,30,31,32],{},"C’è una verità poco comoda: ",[14,33,34],{},"il software amplifica i problemi organizzativi: li rende più evidenti e più rigidi.",[11,36,37],{},"Se il tuo processo è chiaro ma manuale, il software lo velocizza. Se il tuo processo è lento ma ben definito, il software lo automatizza. Se invece il tuo processo è fatto di eccezioni, decisioni caso per caso e regole implicite, il software trasformerà tutto questo in una rete di condizioni difficili da capire e ancora più difficili da modificare.",[11,39,40],{},"Il codice ha bisogno di regole esplicite. Se tu non riesci a spiegare come funziona il tuo processo senza dire “dipende” ogni due frasi, chi sviluppa dovrà tradurre ogni “dipende” in una condizione diversa. E il risultato sarà un sistema che riflette esattamente quella confusione.",[25,42,44],{"id":43},"segnali-che-il-problema-sta-a-monte-del-software","Segnali che il problema sta a monte del software",[46,47,49],"h3",{"id":48},"ci-servono-molte-eccezioni","“Ci servono molte eccezioni”",[11,51,52],{},"Durante l’analisi, se ogni requisito è seguito da “sì, ma in questo caso è diverso”, non sei davanti a un processo: sei davanti a una serie di abitudini stratificate nel tempo.",[11,54,55],{},"Un sistema sano ha poche eccezioni ben definite. Un sistema caotico è composto quasi solo da eccezioni.",[46,57,59],{"id":58},"non-riesco-a-spiegarti-come-funziona","“Non riesco a spiegarti come funziona”",[11,61,62],{},"Prova a scrivere su un foglio le regole del tuo business: come si calcola il prezzo, come si applicano gli sconti, come funziona la fatturazione, come gestisci gli ordini.",[11,64,65],{},"Se non riesci a farlo in modo lineare, probabilmente non stai descrivendo un processo, ma una serie di decisioni prese caso per caso nel tempo.",[46,67,69],{"id":68},"ogni-cliente-è-un-caso-a-sé","“Ogni cliente è un caso a sé”",[11,71,72],{},"C’è una differenza netta tra personalizzazione strutturata e caos. Nel primo caso hai pochi modelli chiari combinabili tra loro; nel secondo ogni cliente ha condizioni uniche, negoziate a voce e mai formalizzate. La prima situazione si può automatizzare. La seconda va prima ricondotta a regole.",[25,74,76],{"id":75},"cosa-succede-quando-digitalizzi-il-caos","Cosa succede quando digitalizzi il caos",[11,78,79,80,85],{},"Nella pratica si vedono sempre gli stessi effetti. Il software diventa difficile da mantenere, perché ogni nuova funzionalità deve tenere conto di tutte le eccezioni precedenti e le modifiche diventano lente, rischiose e costose. Il sistema finisce per diventare ",[81,82,84],"a",{"href":83},"/blog/software-fragile-paura-di-deployare","fragile e ogni deploy diventa fonte di tensione",".",[11,87,88,89,85],{},"Nel frattempo il team continua a lavorare “a parte”. Le persone evitano il software perché per certi casi è ancora più veloce fare a mano, quindi fogli Excel ed email continuano a vivere in parallelo. E naturalmente i costi crescono più del previsto: il costo del software dipende dalla complessità delle regole, non dalla dimensione dell'azienda. Poche regole chiare portano a un sistema semplice, mentre molte regole implicite portano a un sistema costoso e difficile. Del resto ",[81,90,92],{"href":91},"/blog/semplice-e-la-cosa-piu-difficile","costruire qualcosa di semplice è già di per sé la cosa più difficile",[25,94,96],{"id":95},"prima-organizzi-poi-digitalizzi","Prima organizzi, poi digitalizzi",[11,98,99,100,104],{},"Prima di iniziare un progetto software, spesso conviene fare un lavoro preliminare molto più semplice di quanto sembri: chiarire le regole. È lo stesso principio per cui ",[81,101,103],{"href":102},"/blog/stime-sviluppo-sbagliate-perche","le stime di sviluppo sono spesso sbagliate",": senza regole chiare, non si può stimare nulla con precisione.",[11,106,107],{},"La prima domanda utile riguarda il listino. Se la risposta è “dipende dal cliente”, allora la domanda successiva è se possa dipendere da meno fattori: fasce, categorie, criteri ripetibili che coprano la maggior parte dei casi. La seconda riguarda il rapporto tra regole ed eccezioni. Se le eccezioni sono più delle regole, non sei pronto per un software; sei pronto per semplificare il processo. La terza domanda è cosa puoi standardizzare senza perdere valore, perché molte differenze percepite come fondamentali in realtà non lo sono. Il cliente vede il risultato finale, non il metodo interno con cui lo ottieni.",[25,109,111],{"id":110},"il-ruolo-di-chi-progetta-il-software","Il ruolo di chi progetta il software",[11,113,114],{},"Il lavoro più prezioso sta nell'aiutare a riformulare i requisiti prima ancora di tradurli in codice.",[11,116,117,118,121],{},"“Ogni cliente ha il suo prezzo” può diventare “abbiamo un sistema di fasce con alcune deroghe documentate”.",[119,120],"br",{},"\n“Ogni progetto è diverso” può diventare “abbiamo un modello con opzioni configurabili”.",[11,123,124],{},"Questa fase è chiarificazione del modello di business.",[25,126,128],{"id":127},"una-checklist-pratica","Una checklist pratica",[11,130,131],{},"Se riesci a spiegare il tuo processo principale senza usare “dipende” più di una volta, se le eccezioni sono poche e sai elencarle, se le regole che applichi oggi sono scritte da qualche parte, se due persone diverse nella tua azienda descrivono il processo nello stesso modo e se un nuovo collaboratore potrebbe impararlo leggendo quelle regole, allora probabilmente sei pronto a digitalizzare. Se molte di queste risposte sono negative, il lavoro da fare è prima di tutto organizzativo.",[25,133,135],{"id":134},"in-sintesi","In sintesi",[11,137,138],{},"Il software è un acceleratore. Accelera quello che già esiste.",[11,140,141],{},"Se esiste ordine, accelera l’ordine. Se esiste confusione, accelera la confusione.",[11,143,144],{},"Mettere ordine prima di digitalizzare è il modo più efficace per evitare un software costoso che riflette problemi invece di risolverli.",{"title":146,"searchDepth":147,"depth":147,"links":148},"",2,[149,150,156,157,158,159,160],{"id":27,"depth":147,"text":28},{"id":43,"depth":147,"text":44,"children":151},[152,154,155],{"id":48,"depth":153,"text":49},3,{"id":58,"depth":153,"text":59},{"id":68,"depth":153,"text":69},{"id":75,"depth":147,"text":76},{"id":95,"depth":147,"text":96},{"id":110,"depth":147,"text":111},{"id":127,"depth":147,"text":128},{"id":134,"depth":147,"text":135},"Architettura","2026-04-14","Se i tuoi processi non sono chiari, il software li renderà solo più difficili da cambiare. Prima definisci le regole, poi digitalizzi.","md","/images/blog/software-non-risolve-caos-organizzativo.jpg",{},"/blog/2026-04-14-software-non-risolve-caos-organizzativo",{"title":6,"description":163},"Digitalizzazione processi aziendali: prima fai ordine","software-non-risolve-caos-organizzativo","blog/2026-04-14-software-non-risolve-caos-organizzativo",[173,174,175,176,177],"analisi","prodotto","strategia","organizzazione","startup",null,"N6rc0WqAQs48a8wesNVUP3oxGqqIGSrama1JmsBbhYA",[181,323,467],{"id":182,"title":183,"body":184,"category":161,"date":310,"description":311,"extension":164,"image":312,"meta":313,"navigation":3,"path":314,"published":3,"seo":315,"seoTitle":316,"slug":317,"stem":318,"tags":319,"updated":178,"__hash__":322},"blog/blog/2026-04-09-semplice-e-la-cosa-piu-difficile.md","Facile da usare è la cosa più difficile da costruire",{"type":8,"value":185,"toc":299},[186,192,195,199,203,206,213,216,220,223,226,233,237,244,247,250,254,257,260,268,272,275,278,281,284,288,291,293,296],[11,187,188,191],{},[14,189,190],{},"\"Voglio un software semplice. Che basti fare click.\""," È una richiesta legittima, spesso anche la più corretta. Ma la semplicità nel software è un punto di arrivo, mai di partenza. E di solito costa più di quanto chi commissiona si aspetti, perché richiede di prendere molte decisioni al posto dell'utente e gestire in modo invisibile decine di scenari.",[11,193,194],{},"Nel software vale una regola pratica: è facile aggiungere opzioni, campi, passaggi. È più difficile toglierli senza perdere informazioni importanti, senza creare errori e senza aumentare le eccezioni.",[25,196,198],{"id":197},"perché-semplice-è-una-richiesta-costosa","Perché “semplice” è una richiesta costosa",[46,200,202],{"id":201},"dietro-ogni-click-ci-sono-molte-decisioni","Dietro ogni click ci sono molte decisioni",[11,204,205],{},"Quando l’utente preme un bottone e “succede tutto”, la complessità è stata spostata dietro le quinte.",[11,207,208,209,212],{},"Ogni scelta che l’utente ",[14,210,211],{},"non"," fa più (perché non vede un campo, non sceglie un’opzione, non legge un’istruzione) è una scelta che il sistema fa per lui. E per farla bene serve capire contesto, regole, eccezioni, priorità.",[11,214,215],{},"Esempio tipico: “un click per generare la fattura”. Dietro a quel gesto ci sono l’identificazione corretta del cliente e del contesto, i calcoli coerenti con le regole del caso, la numerazione progressiva, la generazione del formato richiesto e l’invio ai sistemi esterni, oltre alla gestione degli esiti e alla comunicazione all’utente. A chi usa il prodotto interessa un click; al team interessa che quel click non produca una fattura sbagliata, un invio fallito o uno stato incoerente. È qui che si annida il costo.",[46,217,219],{"id":218},"togliere-richiede-capire-aggiungere-richiede-soprattutto-implementare","Togliere richiede capire. Aggiungere richiede soprattutto implementare.",[11,221,222],{},"La strada “veloce” verso una prima versione spesso è: mostrare tutto e chiedere tutto all’utente (più campi, più opzioni, più passaggi). Funziona, ma scarica complessità e rischio sull’utilizzatore.",[11,224,225],{},"La strada verso la semplicità, invece, richiede analisi: capire quali informazioni sono davvero necessarie, quali si possono dedurre, quali si possono precompilare, quali si possono rimandare, quali non servono proprio.",[11,227,228,229,232],{},"Questo è il motivo per cui molte richieste di “semplicità” richiedono più iterazioni rispetto a una UI “piena di opzioni”. Perché richiede più decisione che codice. Ed è anche il motivo per cui ",[81,230,231],{"href":102},"le stime di sviluppo sono spesso imprecise",": la complessità sta nelle decisioni, prima che nel codice.",[25,234,236],{"id":235},"il-paradosso-della-semplicità","Il paradosso della semplicità",[11,238,239,240,85],{},"Una UI complessa è spesso il risultato “naturale” di un progetto: si aggiunge quello che serve, poi un’eccezione, poi un’altra, poi un caso particolare. Alla fine si consegna qualcosa che \"fa tutto\", ma che richiede training e supporto. È la dinamica tipica dello ",[81,241,243],{"href":242},"/blog/scope-creep-non-e-agilita","scope creep",[11,245,246],{},"Una UI semplice, al contrario, è il risultato di un lavoro di riduzione: capire cosa è essenziale, togliere il superfluo, automatizzare il resto, e verificare con persone reali che ciò che sembra ovvio lo sia davvero.",[11,248,249],{},"È per questo che “semplice” è un obiettivo di prodotto, non una scorciatoia di sviluppo.",[25,251,253],{"id":252},"semplice-e-subito-raramente-convivono","“Semplice” e “subito” raramente convivono",[11,255,256],{},"Qui nasce la tensione tipica: chi commissiona vuole un’esperienza “a prova di click” e tempi stretti.",[11,258,259],{},"Quando i tempi sono compressi, la probabilità più alta è questa: si consegna una versione che funziona ma è più “carica”, perché non c’è stato spazio per iterare, testare, rivedere e togliere.",[11,261,262,263,267],{},"La soluzione più onesta, di solito, è: partire con poco, farlo funzionare bene, e semplificare in iterazioni successive. È la logica del ",[81,264,266],{"href":265},"/blog/lancia-prima-migliora-dopo","lanciare presto e migliorare",", applicata alla UX: le prime versioni devono essere affidabili, poi diventano davvero semplici.",[25,269,271],{"id":270},"come-si-costruisce-davvero-la-semplicità","Come si costruisce davvero la semplicità",[11,273,274],{},"Molte richieste nascono dal desiderio di “digitalizzare ciò che facciamo oggi”. Ma replicare un processo esistente spesso significa replicarne anche i difetti. La domanda utile è un’altra: qual è il risultato che vogliamo ottenere, e qual è il percorso più diretto per arrivarci?",[11,276,277],{},"In analisi conviene togliere prima di aggiungere. Ogni “e se” introduce complessità, e dopo dieci “e se” il software che doveva essere semplice diventa un gestionale completo. La regola pratica è chiedersi, per ogni feature proposta, se il flusso principale funzionerebbe anche senza. Se la risposta è sì, quella feature può restare fuori dalla versione 1.",[11,279,280],{},"La semplicità poi va provata con utenti reali, presto. Non si decide in riunione. Si verifica sul campo, mettendo anche un prototipo grezzo davanti alle persone che useranno davvero il prodotto. Se la cosa principale si capisce senza spiegazioni, sei sulla strada giusta. Se servono istruzioni o manuali, la complessità è ancora tutta in superficie.",[11,282,283],{},"Infine bisogna accettare che la semplicità è un processo. La versione 1 raramente è davvero semplice; la versione 3 spesso lo è di più, la versione 5 ancora di più. La differenza la fanno le iterazioni guidate da osservazione e feedback, non la quantità di feature inserite fin dall’inizio.",[25,285,287],{"id":286},"euristiche-pratiche-per-chi-commissiona-software","Euristiche pratiche per chi commissiona software",[11,289,290],{},"Quando chiedi un software “semplice”, ci sono alcune domande che aiutano a evitare metà dei fraintendimenti. Bisogna chiarire semplice per chi, perché l’esperienza di un operatore esperto non è quella di un utente occasionale o di un cliente finale. Bisogna capire dove deve essere semplice: nel flusso principale, nelle eccezioni, nella configurazione, nell’onboarding. Vale la pena chiedersi anche cosa può andare storto e come il sistema dovrebbe reagire, che cosa è accettabile rimandare per non appesantire la prima versione e soprattutto qual è il costo dell’errore. Se l’errore costa molto, come succede con fatture, pagamenti o dati delicati, la semplicità richiede più rigore e più test.",[25,292,135],{"id":134},[11,294,295],{},"Un’interfaccia con 30 campi spesso costa meno da costruire nel breve periodo. Un’interfaccia con 3 campi e un bottone spesso costa di più perché richiede analisi, decisioni e gestione invisibile degli edge case. Ma nel medio periodo, la seconda riduce formazione, errori, supporto e frustrazione.",[11,297,298],{},"Se il team è prudente quando sente “semplice”, è consapevolezza del lavoro necessario per farlo bene.",{"title":146,"searchDepth":147,"depth":147,"links":300},[301,305,306,307,308,309],{"id":197,"depth":147,"text":198,"children":302},[303,304],{"id":201,"depth":153,"text":202},{"id":218,"depth":153,"text":219},{"id":235,"depth":147,"text":236},{"id":252,"depth":147,"text":253},{"id":270,"depth":147,"text":271},{"id":286,"depth":147,"text":287},{"id":134,"depth":147,"text":135},"2026-04-09","La semplicità nel software è il punto di arrivo, non di partenza. Un prodotto dove basta un click richiede analisi, decisioni e gestione degli scenari.","/images/blog/semplice-e-la-cosa-piu-difficile.jpg",{},"/blog/2026-04-09-semplice-e-la-cosa-piu-difficile",{"title":183,"description":311},"Semplicità nel software: perché costa più di quanto pensi","semplice-e-la-cosa-piu-difficile","blog/2026-04-09-semplice-e-la-cosa-piu-difficile",[174,320,173,175,321],"user-experience","sviluppo-software","de5RTqVpenTO9sxBaPQGo5iYUKyqqQpx0vU9Fr1YEM8",{"id":324,"title":325,"body":326,"category":161,"date":453,"description":454,"extension":164,"image":455,"meta":456,"navigation":3,"path":457,"published":3,"seo":458,"seoTitle":459,"slug":460,"stem":461,"tags":462,"updated":178,"__hash__":466},"blog/blog/2026-04-07-codice-perfetto-non-serve-a-niente.md","Il codice perfetto che non risolve nulla non serve a niente",{"type":8,"value":327,"toc":440},[328,334,337,341,344,347,350,354,362,366,369,372,376,380,383,386,390,398,402,405,409,412,416,424,428,434,437],[11,329,330,333],{},[14,331,332],{},"Capita più spesso di quanto si pensi: codice scritto molto bene dal punto di vista tecnico, architettura pulita, test completi."," Poi il cliente lo guarda e capisce che non risponde al bisogno per cui era stato commissionato. La tensione tra codice perfetto e codice pragmatico nasce proprio qui: il codice ha senso quando risolve un problema reale.",[11,335,336],{},"La qualità tecnica è importante. Ma solo quando è al servizio del risultato di business. Quando diventa un obiettivo in sé, rischia di rallentare il progetto senza produrre valore percepibile.",[25,338,340],{"id":339},"il-software-è-uno-strumento","Il software è uno strumento",[11,342,343],{},"Chi scrive codice sviluppa naturalmente un senso estetico: si impara a distinguere codice chiaro da codice confuso, strutture solide da soluzioni improvvisate. Questa sensibilità è preziosa.",[11,345,346],{},"Il problema nasce quando “questo codice non mi piace” diventa un motivo sufficiente per fermarsi e riscrivere, anche se quel codice funziona e nessun utente ne percepisce i limiti.",[11,348,349],{},"Il software è uno strumento. Il suo scopo è produrre un risultato. La qualità interna conta, ma è subordinata a ciò che il prodotto deve ottenere all’esterno.",[25,351,353],{"id":352},"quando-la-qualità-diventa-un-costo","Quando la qualità diventa un costo",[11,355,356,357,361],{},"Ci sono situazioni ricorrenti in cui l’attenzione alla perfezione tecnica produce più costi che benefici. Succede quando moduli stabili vengono riscritti solo per renderli più eleganti, quando si introducono astrazioni “per il futuro” che poi non arriva mai, quando si ottimizzano prestazioni in parti del sistema che hanno carichi minimi o quando partono refactoring estesi, a volte vere e proprie ",[81,358,360],{"href":359},"/blog/riscrivere-da-zero-errore","riscritture da zero",", mentre il cliente sta aspettando funzionalità nuove. In tutti questi casi, il tempo viene investito in qualcosa che migliora il codice ma non il prodotto percepito dagli utenti.",[25,363,365],{"id":364},"il-punto-non-è-scrivere-codice-brutto","Il punto non è scrivere codice brutto",[11,367,368],{},"“Meglio un codice brutto che funziona” è una frase pericolosa se presa alla lettera.",[11,370,371],{},"Conviene ragionare come su una scala di priorità. Prima di tutto il codice deve risolvere il problema; se non lo fa, tutto il resto perde importanza. Poi deve essere affidabile, cioè non introdurre bug, problemi di sicurezza o instabilità. Infine deve poter essere modificato senza traumi, con nomi comprensibili, una struttura ragionevole e senza trappole nascoste. Se queste tre condizioni sono rispettate, il codice è già a un livello adeguato per la maggior parte delle fasi di un progetto.",[25,373,375],{"id":374},"le-situazioni-in-cui-si-sbaglia-più-spesso","Le situazioni in cui si sbaglia più spesso",[46,377,379],{"id":378},"il-refactoring-non-richiesto","Il refactoring non richiesto",[11,381,382],{},"Un modulo funziona da mesi senza problemi, ma “internamente è brutto”. Si decide di riscriverlo. Il risultato tipico è tempo speso senza beneficio diretto e, a volte, l’introduzione di nuovi bug in qualcosa che era già stabile.",[11,384,385],{},"Il codice che funziona in produzione da tempo è già stato testato dal caso reale. Cambiarlo senza una motivazione di business è spesso un rischio inutile.",[46,387,389],{"id":388},"lastrazione-prematura","L’astrazione prematura",[11,391,392,393,397],{},"Si introduce un pattern o un livello di astrazione pensando a futuri scenari che, nella pratica, non si presentano. I ",[81,394,396],{"href":395},"/blog/design-pattern-valgono-piu-di-qualsiasi-linguaggio","design pattern hanno valore"," quando risolvono un problema reale, non quando anticipano un problema immaginario. Questo rende il codice più complesso oggi per un beneficio ipotetico domani.",[46,399,401],{"id":400},"le-ottimizzazioni-premature","Le ottimizzazioni premature",[11,403,404],{},"Si investe tempo per rendere una parte del sistema estremamente performante quando i volumi reali non lo richiedono. Quel tempo poteva essere investito in funzionalità che gli utenti stavano aspettando.",[25,406,408],{"id":407},"le-euristiche-pratiche-quando-fermarsi-e-quando-no","Le euristiche pratiche: quando fermarsi e quando no",[11,410,411],{},"Ci sono alcune regole semplici che aiutano a decidere. Vale la pena fermarsi a migliorare il codice quando sta causando bug ricorrenti, rende molto difficile aggiungere nuove funzionalità, nessuno nel team capisce davvero come funziona oppure crea rischi di sicurezza o di stabilità. Al contrario, conviene andare avanti quando quel codice funziona da tempo senza problemi, il cambiamento sarebbe solo estetico o strutturale, il beneficio sarebbe percepito solo dagli sviluppatori e ci sono feature di business più urgenti in attesa. Queste euristiche aiutano a mantenere la qualità sotto controllo senza trasformarla nel centro del progetto.",[25,413,415],{"id":414},"il-concetto-di-abbastanza-buono","Il concetto di “abbastanza buono”",[11,417,418,419,423],{},"“Abbastanza buono” non significa mediocrità. Significa proporzionare lo sforzo al valore: nomi chiari anche se non impeccabili, una struttura leggibile senza rigidità accademiche, ",[81,420,422],{"href":421},"/blog/test-coverage-100-bugia","test sui flussi critici e non ovunque",", e un codice pronto a cambiare senza pretendere di prevedere ogni possibile futuro. Questo livello è sufficiente per permettere al prodotto di evolvere senza rallentare il business.",[25,425,427],{"id":426},"per-chi-decide","Per chi decide",[11,429,430,431],{},"Se il tuo team consegna in ritardo ma il codice è sempre “impeccabile”, vale la pena fare una domanda semplice: ",[14,432,433],{},"quanto di quello che state facendo questa settimana sarà visibile o utile per un utente?",[11,435,436],{},"Se la risposta è “poco”, probabilmente c’è uno squilibrio tra qualità interna e valore esterno.",[11,438,439],{},"Il software migliore non è quello scritto meglio. È quello che risolve il problema giusto, al momento giusto, con il livello di qualità adeguato a quella fase del prodotto.",{"title":146,"searchDepth":147,"depth":147,"links":441},[442,443,444,445,450,451,452],{"id":339,"depth":147,"text":340},{"id":352,"depth":147,"text":353},{"id":364,"depth":147,"text":365},{"id":374,"depth":147,"text":375,"children":446},[447,448,449],{"id":378,"depth":153,"text":379},{"id":388,"depth":153,"text":389},{"id":400,"depth":153,"text":401},{"id":407,"depth":147,"text":408},{"id":414,"depth":147,"text":415},{"id":426,"depth":147,"text":427},"2026-04-07","Codice elegante che non risolve un problema di business è un costo, non un valore. Meglio un codice pragmatico che funziona, senza cadere nel caos.","/images/blog/codice-perfetto-non-serve-a-niente.jpg",{},"/blog/2026-04-07-codice-perfetto-non-serve-a-niente",{"title":325,"description":454},"Codice perfetto vs pragmatico: trovare il giusto equilibrio","codice-perfetto-non-serve-a-niente","blog/2026-04-07-codice-perfetto-non-serve-a-niente",[463,464,174,465,175],"architettura","pragmatismo","qualita","C07yyt3ZSMjUErCvpl5Dk_cCG8sUTNdEXyVcSMzV_MI",{"id":468,"title":469,"body":470,"category":161,"date":635,"description":636,"extension":164,"image":637,"meta":638,"navigation":3,"path":639,"published":3,"seo":640,"seoTitle":641,"slug":642,"stem":643,"tags":644,"updated":178,"__hash__":647},"blog/blog/2026-02-24-clean-code-guida-non-bibbia.md","Clean Code è un'ottima guida. Non è la Bibbia",{"type":8,"value":471,"toc":622},[472,477,480,483,487,499,502,505,509,512,516,519,526,529,533,536,539,542,546,552,555,559,562,569,577,581,584,591,595,598,601,605,608,615,619],[11,473,474],{},[14,475,476],{},"Clean Code di Robert C. Martin è uno dei libri più influenti degli ultimi vent’anni nello sviluppo software. Ha aiutato moltissimi team a scrivere codice più leggibile e manutenibile.",[11,478,479],{},"Ho visto anche l’effetto collaterale: team che applicano regole “da libro” senza contesto e finiscono per produrre complessità non necessaria. Codice elegante, sì, ma costoso: più file, più livelli, più cerimonia. E tempi di consegna che si allungano.",[11,481,482],{},"Il problema non è Clean Code. Il problema è trattarlo come dogma invece che come bussola. E quella differenza, nel software, si paga in soldi, tempo e opportunità.",[25,484,486],{"id":485},"cosa-clean-code-fa-bene-molto-bene","Cosa Clean Code fa bene (molto bene)",[11,488,489,490,494,495,498],{},"Prima di criticare, vale la pena riconoscere cosa funziona davvero. I nomi che significano qualcosa sono una forma di manutenzione preventiva: ",[491,492,493],"code",{},"calculateMonthlyRevenue()"," è molto meglio di ",[491,496,497],{},"calc()",", perché riduce il tempo di comprensione, accelera l’onboarding e limita gli errori banali. Lo stesso vale per funzioni piccole e con responsabilità chiara. Non serve l’ossessione delle “5 righe massimo”, ma una funzione leggibile è più facile da testare, modificare e correggere di un blocco enorme che mescola logica, side effect e condizioni.",[11,500,501],{},"Conta molto anche la struttura prevedibile. Convenzioni condivise su stile, organizzazione ed error handling rendono il codice più navigabile e riducono la frizione: meno tempo perso a interpretare scelte arbitrarie.",[11,503,504],{},"Se un team parte dal caos, Clean Code spesso è un upgrade immediato. Il guaio inizia quando “linee guida” diventano “legge”.",[25,506,508],{"id":507},"dove-il-dogma-fa-danni","Dove il dogma fa danni",[11,510,511],{},"Il danno tipico è sempre lo stesso: ottimizzi la forma del codice prima di sapere se quella forma serve.",[46,513,515],{"id":514},"astrarre-troppo-presto","Astrarre troppo presto",[11,517,518],{},"Ridurre duplicazione è utile, ma la duplicazione “piccola” a volte è un compromesso accettabile. Il rischio vero non è ripetere tre righe: è creare un’astrazione sbagliata che vincola tutto il progetto.",[11,520,521,522,525],{},"Una regola pratica: ",[14,523,524],{},"duplica finché non vedi un pattern stabile",". Se il comportamento si sta ancora chiarendo (tipico di prodotti giovani), astrarre subito è come cementare una decisione quando non hai ancora capito la strada.",[11,527,528],{},"Un po’ di duplicazione costa poco. Un’astrazione prematura costa settimane quando scopri che era quella sbagliata.",[46,530,532],{"id":531},"frammentare-il-codice-in-troppi-micro-file","Frammentare il codice in troppi micro-file",[11,534,535],{},"“Classi piccole” è un buon principio finché migliora la comprensione. Oltre una certa soglia diventa frammentazione: per seguire un flusso devi saltare tra 10 file, e la leggibilità peggiora.",[11,537,538],{},"Segnale tipico: “Per capire il login devo aprire 12 classi”. In quel caso hai solo spostato la complessità: da dentro un file a tra file.",[11,540,541],{},"A volte una classe di 150 righe ben organizzata è più leggibile di 8 classi da 20 righe che si rimbalzano responsabilità.",[46,543,545],{"id":544},"test-come-cerimonia","Test come cerimonia",[11,547,548,549,85],{},"L’enfasi sui test è positiva. Ma se diventa “testiamo tutto perché sì”, ottieni una suite enorme che non protegge i flussi critici. È facile finire a testare getter/setter e logica ovvia, mentre restano scoperti i punti dove il business perde davvero soldi (pagamenti, permessi, integrazioni). È lo stesso problema della coverage: ",[81,550,551],{"href":421},"puoi avere numeri alti e non testare ciò che conta",[11,553,554],{},"La domanda giusta non è “quanta coverage?”. È: “che incidente stiamo prevenendo con questo test?”",[46,556,558],{"id":557},"solid-applicato-senza-contesto","SOLID applicato senza contesto",[11,560,561],{},"SOLID è utile su sistemi complessi. Applicato ovunque e subito, può trasformare un progetto semplice in un labirinto di interfacce e livelli.",[11,563,564,565,568],{},"Regola pratica: ",[14,566,567],{},"usa SOLID per ridurre rischio e accoppiamento nei punti caldi"," (moduli core, logica instabile, aree con molte modifiche). Non trasformarlo in un requisito estetico su ogni form e ogni endpoint.",[11,570,571,572,576],{},"Per un ",[81,573,575],{"href":574},"/blog/mvp-non-e-prodotto-mal-fatto","MVP",", spesso la priorità è avere un sistema chiaro, modificabile e consegnato in tempo — più che inseguire l’architettura “da manuale”.",[25,578,580],{"id":579},"il-costo-concreto-del-dogma","Il costo concreto del dogma",[11,582,583],{},"Per chi gestisce un prodotto, questi eccessi si traducono in effetti misurabili. I tempi di consegna si gonfiano perché la “forma perfetta” diventa parte implicita del requisito, anche quando nessuno l’aveva chiesta. L’onboarding rallenta, perché più livelli e più frammentazione rendono difficile capire dove mettere mano, soprattutto quando le astrazioni non rispondono a un bisogno reale.",[11,585,586,587,590],{},"Poi c’è il refactoring infinito. Se il team viene premiato più per “pulire” che per consegnare, entra in un ciclo di perfezionamento continuo: il codice migliora marginalmente, mentre il prodotto rallenta. E naturalmente diventano più instabili anche le ",[81,588,589],{"href":102},"stime",", perché stai stimando la feature insieme a tutta la cerimonia che le viene costruita attorno.",[25,592,594],{"id":593},"dovè-il-confine-5-regole-pratiche","Dov’è il confine: 5 regole pratiche",[11,596,597],{},"Il confine pratico si può riassumere così. I nomi chiari vanno quasi sempre scelti, perché hanno un ritorno altissimo e costano poco. Le astrazioni hanno senso quando esistono insieme ripetizione e stabilità; se la logica cambia spesso, conviene aspettare. La leggibilità del flusso conta più della frammentazione elegante: se per capire una feature devi aprire troppi file, hai già perso qualcosa.",[11,599,600],{},"Anche i test vanno scelti per impatto, non per rituale. Ha senso proteggere i flussi che costano soldi quando si rompono, come pagamenti, permessi, integrazioni e regressioni. E soprattutto la qualità va misurata nel tempo, non nel gusto personale. La domanda utile è sempre la stessa: quanto ci costerà cambiare questa cosa tra tre mesi?",[25,602,604],{"id":603},"la-sensibilità-conta-più-delle-regole","La sensibilità conta più delle regole",[11,606,607],{},"Clean Code ti dà un vocabolario e una direzione. Ma la parte che fa la differenza è il giudizio: sapere quando un principio va applicato e quando diventa overhead.",[11,609,610,611,614],{},"Il codice deve servire il business, non vincere un concorso di eleganza. Una cattedrale è impressionante, ma se dovevi costruire una casa abitabile in quattro settimane, hai sbagliato obiettivo. La ",[81,612,613],{"href":91},"semplicità è la cosa più difficile"," da ottenere, e spesso è il segno di vera competenza.",[25,616,618],{"id":617},"come-riconoscere-il-problema","Come riconoscere il problema",[11,620,621],{},"Alcuni segnali sono chiari: feature piccole che diventano “progetti architetturali”, un team che parla spesso di “rifare bene” ma consegna poco, codice apparentemente pulitissimo insieme a onboarding lento, modifiche che richiedono di toccare troppi livelli e troppe classi. In questi casi stai comprando complessità spacciata per qualità.",{"title":146,"searchDepth":147,"depth":147,"links":623},[624,625,631,632,633,634],{"id":485,"depth":147,"text":486},{"id":507,"depth":147,"text":508,"children":626},[627,628,629,630],{"id":514,"depth":153,"text":515},{"id":531,"depth":153,"text":532},{"id":544,"depth":153,"text":545},{"id":557,"depth":153,"text":558},{"id":579,"depth":147,"text":580},{"id":593,"depth":147,"text":594},{"id":603,"depth":147,"text":604},{"id":617,"depth":147,"text":618},"2026-02-24","Le regole di Clean Code salvano progetti dal caos. Ma applicate senza giudizio generano complessità inutile. Dove sta il confine pratico.","/images/blog/clean-code-guida-non-bibbia.jpg",{},"/blog/2026-02-24-clean-code-guida-non-bibbia",{"title":469,"description":636},"Clean Code: guida pratica o dogma da evitare?","clean-code-guida-non-bibbia","blog/2026-02-24-clean-code-guida-non-bibbia",[463,645,646,465,321],"best-practice","debito-tecnico","si3D-ZMxXpjMrm24fFVt83Rsr4zGlDtqXWBckmVS_ac",1776145215558]