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.
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.
Il software è uno strumento
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.
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.
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.
Quando la qualità diventa un costo
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 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.
Il punto non è scrivere codice brutto
“Meglio un codice brutto che funziona” è una frase pericolosa se presa alla lettera.
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.
Le situazioni in cui si sbaglia più spesso
Il refactoring non richiesto
Un modulo funziona da mesi senza problemi, ma “internamente è brutto”. Si decide di riscriverlo. Questo è il classico refactoring, cioè la riorganizzazione del codice senza cambiare ciò che il prodotto fa. Il risultato tipico è tempo speso senza beneficio diretto e, a volte, l’introduzione di nuovi bug in qualcosa che era già stabile.
Il codice che funziona in produzione da tempo è già stato testato dal caso reale. Cambiarlo senza una motivazione di business è spesso un rischio inutile.
L’astrazione prematura
Si introduce un pattern o un livello di astrazione pensando a futuri scenari che, nella pratica, non si presentano. I 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.
Le ottimizzazioni premature
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.
Le euristiche pratiche: quando fermarsi e quando no
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.
Il concetto di “abbastanza buono”
“Abbastanza buono” non significa mediocrità. Significa proporzionare lo sforzo al valore: nomi chiari anche se non impeccabili, una struttura leggibile senza rigidità accademiche, 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.
Per chi decide
Se il tuo team consegna in ritardo ma il codice è sempre “impeccabile”, vale la pena fare una domanda semplice: quanto di quello che state facendo questa settimana sarà visibile o utile per un utente?
Se la risposta è “poco”, probabilmente c’è uno squilibrio tra qualità interna e valore esterno.
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.
Simone Giusti
Consulente software strategico
