“Se funziona, non toccare” — cos’è, essenza del principio e rischi

Cos’è il principio “se funziona, non toccare”?

“Se funziona, non toccare” — è una regola empirica che mette in guardia gli sviluppatori dall’apportare modifiche al codice funzionante senza motivi sufficienti. Il principio si basa su semplici statistiche: la stragrande maggioranza dei difetti viene introdotta durante la modifica del codice esistente.

Il principio non è un dogma — è piuttosto un’euristica che aiuta a prendere decisioni in condizioni di incertezza. Più la base di codice è complessa e intricata, maggiore è la probabilità che un cambiamento “innocente” rompa qualcosa che nessuno si aspettava di rompere.

Secondo uno studio di Microsoft Corporation (2024), circa il 60% di tutti gli incidenti critici in produzione sono correlati a recenti modifiche del codice apportate con buone intenzioni ma non sufficientemente testate in condizioni di carico reale.

Storia e origine del principio

L’idioma “Se non è rotto, non aggiustarlo” risale alla cultura ingegneristica americana della metà del XX secolo. L’uso documentato più antico è attribuito a Bert Lance (1977), che lavorava nella Commissione Finanze del Senato americano e si opponeva alla regolamentazione eccessiva.

Nella programmazione, il principio proviene dall’ingegneria hardware, dove sostituire un chip funzionante con uno nuovo poteva portare a conseguenze imprevedibili. Nel contesto del software, questo principio ha guadagnato particolare diffusione con la crescente complessità dei sistemi software e l’emergere del codice legacy.

Interessante notare che nella programmazione il principio ha anche un rovescio della medaglia — “funziona, ma è meglio non toccarlo” diventa spesso una scusa per evitare il refactoring, portando a lungo termine a un accumulo critico di debito tecnico. Secondo la società di consulenza Thoughtworks (2023), circa il 40% dei progetti affronta seri problemi a causa di un conservatorismo eccessivo riguardo ai cambiamenti.

Quando applicare il principio

Il principio “se funziona, non toccare” è particolarmente rilevante in situazioni in cui il costo di un errore supera il potenziale beneficio dei cambiamenti.

Progetti legacy senza test

Nel codice legacy non coperto da test, qualsiasi cambiamento è una roulette russa. Se uno sviluppatore non può verificare che il cambiamento non abbia rotto i moduli adiacenti, la strategia migliore è non toccare il codice funzionante. L’eccezione riguarda solo bug critici o requisiti di sicurezza.

Sistemi critici

Nei sistemi in cui il downtime è inaccettabile o il costo di un errore è enorme — software medico, avionica, transazioni finanziarie — il principio “se funziona, non toccare” è lo standard de facto. Ogni cambiamento passa attraverso un’approvazione e test a più livelli.

Scadenze strette

Se il rilascio è domani e il codice funziona — non cercare di migliorarne l’architettura. Modifica solo ciò che influisce direttamente sulla funzionalità del rilascio. Rimanda il refactoring allo sprint successivo (ma non dimenticarlo).

Rischi nel seguire il principio

Seguire ciecamente il principio “se funziona, non toccare” comporta rischi non inferiori a un refactoring infinito. Esaminiamo i principali pericoli.

Accumulo di debito tecnico

Se ogni sviluppatore segue questo principio, la base di codice si trasforma rapidamente in una “torta a strati” di soluzioni obsolete, workaround e algoritmi subottimali. Prima o poi, il debito tecnico diventa insostenibile — qualsiasi cambiamento richiede settimane di analisi.

Opportunità di ottimizzazione perse

A volte, un cambiamento che sembra rischioso migliora significativamente le prestazioni o la sicurezza. Il principio “se funziona, non toccare” non dovrebbe bloccare i cambiamenti che portano benefici misurabili — ridurre i costi del server, accelerare il caricamento delle pagine, migliorare la sicurezza.

Perdita di competenze

Quando un team non tocca certe parti del codice per anni, perde la comprensione di come funzionano. Lo sviluppatore chiave se ne va — e il codice diventa legacy senza possibilità di supporto. Il principio dovrebbe essere applicato tenendo conto della manutenibilità a lungo termine del progetto.

Il giusto mezzo: refactoring senza fanatismo

La strategia ottimale non è seguire il principio ciecamente, ma applicarlo consapevolmente, tenendo conto del contesto. Il refactoring è necessario, ma deve essere sicuro.

La regola del boy scout

La regola del boy scout nella programmazione: “Lascia il codice più pulito di come l’hai trovato.” Se uno sviluppatore apporta una modifica a un modulo, dovrebbe migliorarne la struttura, ma entro limiti ragionevoli. Non riscrivere tutto da zero, ma almeno rinominare le variabili illeggibili e aggiungere commenti.

Refactoring sotto protezione dei test

I test sono l’unico modo per applicare in sicurezza il principio “se funziona, non toccare”. Se il codice è coperto da test, qualsiasi refactoring diventa prevedibile: lo sviluppatore modifica il codice, esegue i test e vede se qualcosa si è rotto. Senza test — non toccare. Con i test — refactoring con fiducia.

// Esempio: refactoring sicuro sotto copertura di test
class PriceCalculator {
    fun calculatePrice(basePrice: Double, discount: Double): Double {
        // Codice vecchio ma funzionante
        return basePrice - (basePrice * discount / 100.0)
    }
}

// Test che protegge dalla regressione
class PriceCalculatorTest {
    fun testCalculatePrice() {
        val calc = PriceCalculator()
        assertEquals(90.0, calc.calculatePrice(100.0, 10.0))
    }
}

Questo esempio dimostra l’approccio corretto: prima il test, poi il refactoring. Se il test passa, la modifica è sicura. Il principio “se funziona, non toccare” si trasforma in “se funziona sotto test, refactoring con coraggio.”

Esempi reali dalla pratica

Esaminiamo scenari reali in cui il principio “se funziona, non toccare” si è rivelato sia salvifico che distruttivo.

Caso salvifico: problema simile a Y2K

Uno sviluppatore ha scoperto che il codice di elaborazione delle date utilizzava il formato DD/MM/AA invece di AAAA. Il codice funzionava correttamente dal 2000 al 2025. Nonostante il desiderio di “correggerlo”, ha lasciato il codice com’era, limitandosi a un commento. Nel 2026, l’azienda ha aggiornato il sistema e la nuova soluzione gestiva correttamente i secoli. Un cambiamento prematuro avrebbe rotto la logica funzionante.

Caso distruttivo: perdita di dati dovuta a “miglioramento”

Un ingegnere ha deciso di “migliorare” il vecchio codice di importazione dati, che funzionava, sostituendolo con una libreria moderna. Non ha considerato che la vecchia libreria gestiva un caso limite specifico che non era documentato. Dopo il rilascio — perdita massiva di dati. Il principio “se funziona, non toccare” è stato violato, e il costo dell’errore è stato di due settimane di lavoro del team per il recupero.