Le stampelle in programmazione — cosa sono, cause e quando sono giustificate

Cos'è una “stampella” in programmazione

Una stampella (crutch) è una soluzione software che funziona ma è fatta “di fretta”: risolve un problema specifico ma non ne elimina la causa, non segue l'architettura del progetto e può rompersi al minimo cambiamento nell'ambiente. La metafora è calzante — come una vera stampella, questo codice aiuta a “camminare” ma non guarisce la “gamba.”

Gli sviluppatori “puntellano con stampelle” bug, incompatibilità di versione, peculiarità della piattaforma e requisiti urgenti del cliente. Una stampella tipica è una stampella condizionale: se iOS 15, aggiungi un margine; se Huawei, nascondi il pulsante. Questi controlli si moltiplicano e trasformano il codice in un “strato di torta” di rami di piattaforma e versione.

Le stampelle esistono a diverse scale: da una singola riga con una condizione di stampella a un intero modulo wrapper che “corregge” il comportamento di una libreria. È importante capire che una stampella non è sempre negativa: nelle mani giuste, è uno strumento che consente di rilasciare un prodotto in tempo. Il problema inizia quando la stampella rimane nel codice per sempre.

Perché compaiono le stampelle: cause e contesto

La ragione principale della comparsa delle stampelle è il conflitto tra la soluzione ideale e i vincoli reali del progetto. Lo sviluppatore sa come fare correttamente, ma il tempo, il denaro o le limitazioni tecniche lo impediscono. Il risultato è una soluzione di compromesso che “semplicemente funziona.”

Esaminiamo quattro ragioni principali per cui gli sviluppatori ricorrono consapevolmente alle stampelle. Comprendere queste ragioni aiuta a trattare le stampelle non come un errore ma come uno strumento pragmatico che deve essere gestito.

Scadenze

La ragione più comune. Il rilascio è domani, il bug si riproduce solo su un modello specifico e risolverlo architetturalmente richiederebbe due settimane. Una stampella condizionale richiede un'ora e risolve il problema. Dopo il rilascio, il team promette di tornare e riscrivere correttamente. “Niente è più permanente di una soluzione temporanea” — vale esattamente per queste stampelle.

Incompatibilità di versione

La libreria A richiede Android 12, ma la tua app supporta Android 10. La soluzione è scrivere un wrapper che controlla la versione del SO e seleziona il percorso di esecuzione. Questa è una stampella perché quando la libreria verrà aggiornata, il wrapper dovrà essere riscritto. Ma l'alternativa — abbandonare la libreria o il supporto per i vecchi dispositivi — potrebbe essere peggiore.

// Stampella per compatibilità API 29
if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.R) {
    useModernApi()
} else {
    useLegacyFallback()
}

Dipendenze di terze parti con bug

Una libreria da cui il progetto dipende ha un bug, ma aggiornarla potrebbe richiedere settimane (PR necessaria, revisione del codice, pubblicazione). Invece di aspettare, il team scrive un wrapper che corregge il comportamento della libreria al volo. Quando viene rilasciata la versione corretta della libreria, il wrapper viene rimosso. Se non viene rimosso, è già un problema architetturale.

Comprensione incompleta del sistema

Un nuovo sviluppatore in un progetto legacy non capisce perché il codice funziona in quel modo. Invece di capire, aggiunge una nuova condizione sopra quelle esistenti. Questo è il tipo di stampella più pericoloso perché l'autore non si rende conto che è una stampella. L'unico rimedio è la revisione del codice e la programmazione in coppia per i nuovi membri del team.

Quando una stampella è giustificata: approccio pragmatico

Non ogni stampella è negativa. Nello sviluppo reale, la purezza assoluta del codice è irraggiungibile e spesso poco pratica. Un approccio pragmatico riconosce che le soluzioni temporanee fanno parte del processo, ma richiede consapevolezza, documentazione e un piano di rimozione. Una stampella è giustificata quando risolve un problema di business più velocemente di una soluzione architetturale pulita.

I criteri per una stampella giustificata: risolve un problema specifico, ha un proprietario (qualcuno responsabile della sua rimozione) ed esiste un piano di refactoring. Se manca almeno una di queste tre condizioni, la stampella si trasforma in debito tecnico. Strumenti come i commenti TODO con un ticket nel tracker sono il metodo minimo di documentazione.

Esempio di una stampella giustificata

Un bug critico nel ramo di rilascio che deve essere corretto prima del deploy di domani. La soluzione pulita richiede un refactoring architetturale e richiederebbe due settimane. La stampella: aggiungere un controllo nil e inviare la correzione come hotfix. Condizioni di giustificazione: è stato creato un ticket di refactoring nel tracker, è stato assegnato un proprietario e la stampella è contrassegnata da un commento. Due settimane dopo, il team torna al compito.

// TODO: IT-1234 — rimuovere questa stampella dopo il refactoring di AuthService
guard let userId = session.user?.id else {
    return Result.failure(.notAuthenticated)
}

Come distinguere una stampella temporanea da un problema architetturale

Il confine tra una stampella consapevole e un problema architetturale (debito tecnico) passa attraverso due parametri: consapevolezza della decisione ed esistenza di un piano per eliminarla. Una stampella è sempre una soluzione temporanea con una durata di vita nota. Il debito tecnico è la conseguenza di molte stampelle lasciate incustodite.

Quando una stampella diventa un problema

La situazione peggiora quando il numero di stampelle supera una massa critica. Ogni nuova stampella aumenta la “fragilità” del sistema: un cambiamento in un punto ne rompe un altro. Alla fine, lo sviluppo rallenta, i bug si moltiplicano e un nuovo sviluppatore non riesce a capire il codice senza l'aiuto dell'autore. A questo punto, le stampelle cessano di essere soluzioni temporanee e diventano un problema architetturale.

Segni di una crisi di stampelle

Se il codice contiene cinque controlli annidati per la versione del SO, il produttore del dispositivo e la presenza di una libreria specifica — non è una stampella, è un problema architetturale. Se l'aggiunta di una correzione causa tre regressioni in moduli correlati — le stampelle non sono più locali. Se le revisioni del codice vengono regolarmente respinte a causa di “un'altra stampella” — è ora di pianificare il refactoring.

• La stessa stampella si ripete in tre o più punti — è ora di creare una soluzione unificata
• Una stampella vive più di tre sprint senza un piano di rimozione — è già debito tecnico
• Un nuovo sviluppatore non capisce perché il codice funziona così — la stampella non è documentata
• La rimozione della stampella provoca una reazione a catena di errori — la dipendenza dalla stampella è diventata architetturale

Refactoring delle stampelle: strategia e pratica

Refactoring delle stampelle è il processo di sostituzione delle soluzioni temporanee con soluzioni architetturalmente corrette. Richiede tempo, quindi è necessaria una strategia di priorità: non tutte le stampelle devono essere eliminate immediatamente. Una buona strategia consiste nel valutare ogni stampella in base a due parametri: la frequenza dei cambiamenti in quell'area di codice e l'impatto sugli utenti.

Strategia di priorità

Priorità alta — stampelle in moduli modificati frequentemente (logica di business, UI generica) che rallentano lo sviluppo e causano regressioni. Priorità media — stampelle in moduli raramente modificati ma con potenziale impatto sugli utenti (elaborazione pagamenti, autorizzazione). Priorità bassa — stampelle in codice legacy che funziona stabilmente e non è previsto per modifica.

Processo di rimozione passo passo

Passo 1: inventario — trova tutti i TODO e FIXME relativi alle stampelle. Passo 2: valutazione — determina quali sono ancora pertinenti. Passo 3: pianificazione — programma il refactoring delle stampelle in uno sprint, iniziando dalle priorità alte. Passo 4: sostituzione — implementa la soluzione pulita, rimuovi la stampella e il suo commento TODO. Passo 5: verifica — assicurati che i test passino e non ci siano regressioni.

# Trovare tutte le stampelle TODO nel progetto
grep -r "TODO\|FIXME\|HACK\|XXX" --include="*.kt" --include="*.swift" .

Prevenzione di nuove stampelle

Il modo migliore per combattere le stampelle è non crearle inutilmente. Prima di scrivere una stampella, fatti tre domande: posso implementare una soluzione pulita in un tempo ragionevole? Esiste un'alternativa che non sia una stampella? Il team avrà tempo per tornare e riscrivere questo? Se la risposta ad almeno una domanda è “no” — ripensa prima di “puntellare” il codice.