Codice spazzatura e caos nei progetti mobili — segnali e refactoring

Cos’è il codice spazzatura nello sviluppo

Il codice spazzatura (anche spaghetti code, caos, big ball of mud) è una metafora per una base di codice che ha perso la sua struttura e si è trasformata in una rete aggrovigliata di dipendenze. In tale codice, qualsiasi modifica in un punto ne rompe un altro, e aggiungere nuove funzionalità diventa un’impresa rischiosa.

Nello sviluppo mobile, il codice spazzatura è particolarmente critico: un’app costruita su un “caos” inizia a rallentare, crashare sui dispositivi vecchi e fa fatica a superare il code review. Un progetto iOS senza architettura potrebbe non superare l’App Review a causa dell’instabilità.

Secondo Stripe, gli sviluppatori trascorrono fino al 42% del loro tempo di lavoro a leggere e comprendere il codice esistente. Nei progetti con codice spazzatura, questa cifra supera il 60%, rendendo lo sviluppo estremamente inefficiente.

Origine dei termini

Spaghetti code è il termine più antico, risalente agli anni ’70. Descrive un codice con un flusso di controllo caotico, che ricorda degli spaghetti aggrovigliati.

Big ball of mud è un termine introdotto da Brian Foote e Joseph Yoder nel 1997 per descrivere sistemi senza un’architettura chiara che crescono caoticamente.

Perché il codice spazzatura è pericoloso per il business

Il codice spazzatura rallenta il rilascio di nuove funzionalità sul mercato. Il team passa il tempo non a creare valore, ma a cercare di capire come funziona il codice esistente e come non rompere nulla.

Secondo McKinsey, le aziende con bassa qualità del codice spendono il 20-40% in più per la manutenzione del prodotto, e la velocità di rilascio di nuove funzionalità è 2-3 volte inferiore rispetto alle aziende con alta qualità del codice.

Segnali di codice spazzatura e come riconoscerlo

Riconoscere il codice spazzatura può essere fatto attraverso una serie di indicatori oggettivi, alcuni dei quali vengono misurati automaticamente. Più indicatori coincidono, più grave è il problema.

Nel settore, vengono utilizzate metriche di qualità del codice come la Complessità di Halstead, l’Indice di Manutenibilità e il Rapporto di Debito Tecnico. Conoscere queste metriche aiuta a valutare oggettivamente lo stato di una base di codice.

Copia-incolla (duplicazione del codice)

Il segnale più comune di codice spazzatura sono i blocchi di codice ripetuti. Invece di estrarre una funzione comune, gli sviluppatori copiano il codice da un posto all’altro con modifiche minime.

Un livello di duplicazione fino al 5% è considerato normale. Se la duplicazione supera il 15%, è un segnale serio. Strumenti come Simian e PMD Copy Paste Detector aiutano a identificare automaticamente il copia-incolla.

Metodi e classi lunghi

Un metodo di oltre 100 righe è un chiaro segnale di codice spazzatura. Tale metodo di solito fa troppo e viola il Principio di Responsabilità Unica.

Le classi con più di 1000 righe di codice sono anch’esse problematiche. Contengono funzionalità non correlate, rendendo difficile testare, comprendere e modificare il codice.

Elevata complessità ciclomatica

La complessità ciclomatica di McCabe è una metrica che mostra il numero di percorsi indipendenti nel codice. Un valore superiore a 15 è considerato problematico.

I metodi con una complessità superiore a 30 sono nella “zona di disastro.” Contengono troppe ramificazioni, rendendoli impossibili da testare e comprendere senza un’analisi approfondita.

Cause del codice spazzatura

Il codice spazzatura non appare “da solo” — è sempre il risultato di determinati processi e decisioni nel team. Comprendere le cause aiuta a prevenirlo in futuro.

Secondo JetBrains Developer Ecosystem 2024, il 67% degli sviluppatori ammette di scrivere codice peggiore di quanto potrebbe a causa della mancanza di tempo. Questa è la ragione principale dell’accumulo di debito tecnico.

Fretta e scadenze

La causa più comune sono le scadenze strette. Il team scrive codice “come viene”, solo per rispettare la scadenza. Refactoring, test e code review vengono rinviati “a dopo.”

Il problema è che “dopo” non arriva mai — nuove scadenze appaiono nello sprint successivo, e il debito tecnico si accumula come una palla di neve.

Mancanza di code review

Senza code review, ogni sviluppatore scrive nel proprio stile, usa i propri pattern e lascia i propri “segni.” Col tempo, la base di codice perde uniformità.

I team che praticano il code review obbligatorio per ogni pull request hanno il 60% di difetti in meno in produzione, secondo uno studio SmartBear 2024.

Architettura debole fin dall’inizio

Se un progetto inizia senza un’architettura chiara, il codice spazzatura è inevitabile. Le prime “soluzioni rapide” gettano le basi su cui è poi difficile costruire qualcosa di qualità.

Nello sviluppo mobile, la scelta dell’architettura (MVC, MVP, MVVM, Clean Architecture) dovrebbe essere una decisione consapevole presa prima di iniziare a scrivere codice, non un risultato dell’evoluzione.

Metodi per combattere il codice spazzatura

Combattere il codice spazzatura richiede un approccio sistematico e disciplina da parte di tutto il team. Non esiste un singolo strumento o pratica che risolva il problema — serve un insieme di misure.

Il principio principale è prevenire il codice spazzatura in fase di scrittura, non correggerlo dopo. La prevenzione è sempre più economica del refactoring di un “caos” esistente.

Standard di codifica

Uno stile di codice unificato è la base per prevenire il codice spazzatura. Gli standard di codifica (Code Style) dovrebbero essere documentati e verificati automaticamente dai linter.

Per iOS si usa SwiftLint, per Android Ktlint e Detekt. Configurare le regole in un file di configurazione permette di rifiutare automaticamente le pull request che violano gli standard.

Refactoring regolare

Il refactoring non è correggere bug, ma migliorare la struttura del codice senza cambiarne il comportamento. Dovrebbe essere una parte regolare del processo di sviluppo, non un progetto separato.

Si consiglia di dedicare il 20% del tempo di ogni sprint al refactoring e al pagamento del debito tecnico. Questo previene l’accumulo di “caos” e mantiene la velocità del team a lungo termine.

Code review obbligatorio

Ogni pull request dovrebbe essere revisionata da almeno uno sviluppatore. Il code review identifica non solo bug, ma anche violazioni dell’architettura, problemi di stile e potenziali fonti di codice spazzatura.

Una buona pratica è una checklist per il code review che include la verifica di copia-incolla, lunghezza dei metodi, complessità ciclomatica e copertura dei test. Senza checklist, i revisori perdono fino al 50% dei problemi.

Strumenti per pulire la base di codice

Gli strumenti moderni di analisi del codice permettono di rilevare automaticamente il codice spazzatura, misurare il debito tecnico e monitorare la qualità. Integrare questi strumenti nella pipeline CI/CD fornisce un monitoraggio continuo.

Si consiglia di utilizzare almeno un analizzatore statico e uno strumento di misurazione delle metriche. Inoltre, è possibile collegare una piattaforma per aggregare i dati sulla qualità del codice.

Analizzatori statici

• SonarQube — la piattaforma leader per l’analisi della qualità del codice, supporta oltre 30 linguaggi e fornisce metriche sul Rapporto di Debito Tecnico
• ESLint — lo standard per JavaScript e TypeScript, configurabile tramite file di configurazione e integrato negli IDE
• SwiftLint — uno strumento obbligatorio per i progetti iOS, verifica la conformità alla Guida di Stile Swift

Secondo SonarSource, i team che utilizzano l’analisi statica riducono il numero di bug in produzione del 30% già nel primo trimestre dopo l’adozione.

Strumenti di misurazione delle metriche

CodeClimate e Codacy sono piattaforme che aggregano metriche di qualità del codice, tracciano le tendenze e mostrano i “punti caldi” — i file con il maggior debito tecnico.

Per i progetti Android, Detekt fornisce oltre 100 regole di analisi integrate, inclusi controlli di complessità ciclomatica, lunghezza dei metodi e duplicazione del codice.