YAGNI nello sviluppo di app: cos'è, l'essenza del principio e il beneficio pratico

Cos'è YAGNI?

YAGNI (You Aren't Gonna Need It) — un principio di programmazione estrema (XP) che significa “non ti servirà”. La regola dice: non implementare mai funzionalità che non sono richieste dalle user story attuali. Se una funzionalità non serve oggi — non realizzarla, nemmeno “per precauzione”.

Il termine è stato coniato da Ron Jeffries, uno dei coautori della metodologia XP (con Kent Beck). Jeffries affermava: “Implementa la cosa più semplice che funziona e non aggiungere nulla finché non è necessario”. YAGNI non è un divieto di pianificare, ma un divieto di implementazione prematura.

Secondo il Standish Group CHAOS Report (2023), il 64% delle funzionalità in un prodotto software medio vengono usate raramente o mai. Estrapolando a un'app mobile — più della metà del codice scritto non porta valore all'utente. YAGNI previene questo spreco di risorse.

Applica YAGNI come un filtro rigoroso: ogni funzionalità deve rispondere alla domanda “che problema specifico dell'utente risolve ora?” Se non c'è risposta — la funzionalità non è necessaria.

Differenza tra YAGNI e pigrizia o scorciatoie

YAGNI non è un rifiuto dell'architettura di qualità. YAGNI vieta di scrivere codice inutile, ma non vieta di scrivere codice corretto. Se una funzionalità attuale ha bisogno di un livello di astrazione pulito — crealo. Se il livello non è necessario — non crearlo. Differenza chiave: YAGNI riguarda la funzionalità, non la qualità.

Gli sviluppatori confondono spesso YAGNI con l'accumulo intenzionale di debito tecnico (il debito tecnico è sempre un compromesso, YAGNI è un principio di efficienza). La differenza è che il debito tecnico viene riconosciuto e documentato, mentre violare YAGNI è semplicemente lavoro extra.

Chiediti: “Se non creo questa astrazione ora, quanto tempo richiederà il refactoring quando sarà necessaria?” Se il tempo di refactoring è inferiore al tempo di scrittura ora — rimandalo.

Perché YAGNI è critico per i progetti mobili?

Lo sviluppo mobile è particolarmente sensibile alle violazioni di YAGNI per tre ragioni: la dimensione dell'APK/IPA influisce direttamente sul tasso di conversione dell'installazione, il tempo di compilazione dei progetti mobili cresce linearmente con il volume di codice e ogni funzionalità extra aggiunge punti di fallimento. YAGNI non riguarda la pigrizia, ma la concentrazione.

Uno studio di Google Play Console Data (2023) ha mostrato: ogni 10 MB di dimensione dell'APK riducono la probabilità di installazione dell'1,2%. Il codice non utilizzato non è solo spazzatura nel repository — è una perdita finanziaria diretta. Librerie extra (per funzionalità che “magari aggiungeremo dopo”) sono la fonte più comune di gonfiamento dell'APK.

Secondo il Gradle Build Performance Report (2024), ogni modulo aggiuntivo in un progetto Android aumenta il tempo di build completo di 3–7 secondi. Se aggiungi 5 moduli “per precauzione” — l'aumento del tempo di build sarà di 15–35 secondi per build. In un anno, un team di 5 sviluppatori perde fino a 200 ore-uomo in attesa della compilazione.

Monitora la dimensione del binario in CI: imposta un limite di avviso (ad esempio, +500 KB per commit). Se la dimensione è aumentata senza una nuova funzionalità — è una violazione di YAGNI che dovrebbe essere discussa nella revisione del codice.

YAGNI vs gold-plating: esempi pratici

Gold-plating: animazione prematura

Gold-plating — aggiungere funzionalità oltre i requisiti nel tentativo di “migliorare” il prodotto. Un esempio tipico: uno sviluppatore aggiunge un'animazione di transizione complessa tra schermate, sebbene il design specifichi un semplice fade. L'animazione richiede 2 giorni, l'utente non la nota e i bug su diversi dispositivi perseguitano il progetto per anni.

Secondo il UX Collective Annual Report (2023), il 78% degli utenti valuta un'app in base a velocità e stabilità, non alle animazioni. YAGNI dice: se l'animazione non è specificata nei requisiti — non implementarla. Il designer aggiungerà l'animazione quando sarà effettivamente necessaria per risolvere un problema di UX.

Implementa solo ciò che è nei mockup. Se il designer non ha disegnato un'animazione — non dovrebbe esistere. Qualsiasi deviazione dal mockup è una violazione di YAGNI.

Localizzazione prematura in 20 lingue

Un errore comune delle startup: costruire immediatamente il supporto per 20+ lingue “per la futura entrata nel mercato internazionale”. YAGNI raccomanda: localizza solo nella lingua del mercato attuale. Aggiungere ogni nuova lingua richiede tempo dei traduttori, test di troncamento delle stringhe e debug dei layout RTL.

Secondo il Deloitte Digital Globalization Survey (2022), il 60% delle app mobili non esce mai dal suo primo mercato. Se è il tuo caso — le risorse spese per il supporto multilingue sono sprecate. Approccio YAGNI: inglese (base) + lingua del mercato target. Le altre — quando entrerai effettivamente in una regione.

Usa YAGNI per prioritizzare: se una funzionalità non è nella roadmap dei prossimi due trimestri — non iniziarla. La roadmap deve essere documentata e approvata dal product manager.

Come applicare YAGNI in Android e iOS?

YAGNI in Android: non aggiungere librerie inutili

I progetti Android soffrono di inflazione di librerie. Gli sviluppatori aggiungono Retrofit, OkHttp, Gson, Room, Dagger Hilt, Navigation Component, DataStore — ancora prima di scrivere la prima riga di logica di business. YAGNI raccomanda: aggiungi librerie secondo le reali necessità, non preventivamente.

// Violazione di YAGNI: inclusione preventiva di librerie
// build.gradle (module)
implementation("com.squareup.retrofit2:retrofit:2.9.0")
implementation("com.squareup.retrofit2:converter-gson:2.9.0")
implementation("androidx.room:room-runtime:2.6.0")

// E l'app mostra semplicemente "Hello World"

Le librerie sono dipendenze con la propria complessità. Ognuna richiede aggiornamenti di versione, migrazione in caso di modifiche sostanziali e aumenta la dimensione dell'APK. Aggiungi una libreria quando emerge un compito specifico che quella libreria risolve. Inizia con OkHttp (client HTTP minimale), aggiungi Retrofit quando ti serve un client REST, e così via.

YAGNI in iOS: non forzare SwiftUI

SwiftUI è un framework potente, ma la sua adozione dovrebbe essere guidata da esigenze reali. Se un progetto inizia con iOS 14+ e i requisiti per componenti UI personalizzati sono minimi — SwiftUI è una buona scelta. Se un progetto deve supportare iOS 13 o richiede gesture personalizzate complesse — UIKit rimane la soluzione giusta. YAGNI è contrario alla migrazione a SwiftUI “perché è di moda”.

// YAGNI: usa UIKit finché non c'è un reale beneficio da SwiftUI
class ProfileViewController: UIViewController {
    override func viewDidLoad() {
        super.viewDidLoad()
        title = "Profilo"
    }
}

// Se SwiftUI è necessario — integra tramite UIHostingController
let swiftUIView = ProfileView()
let hostingVC = UIHostingController(rootView: swiftUIView)

L'analisi di Point-Free: “SwiftUI vs UIKit Decision Guide” (2024) raccomanda: non migrare le schermate UIKit esistenti a SwiftUI senza una chiara ragione di business (ad esempio, la necessità di Live Preview per il designer). Riscrivere codice funzionante è una violazione diretta di YAGNI. SwiftUI — per nuove schermate, UIKit — per quelle esistenti.

Errori tipici nel seguire YAGNI

YAGNI come scusa per una cattiva architettura

L'errore più pericoloso è usare YAGNI come scusa per una cattiva architettura. “Non creeremo un livello di repository perché YAGNI — scriveremo la query direttamente nel ViewModel”. Questo non è YAGNI, è accumulare debito tecnico. YAGNI vieta funzionalità non necessarie, non l'integrità architettonica.

L'architettura è un investimento nella manutenibilità. Se stai scrivendo più di 3 schermate — un livello architettonico di base (MVVM, repository) è già giustificato. Se è 1 schermata — puoi permetterti un approccio più semplice. La chiave: determina il minimo architettonico necessario per le funzionalità attuali e non aggiungere di più.

Dividi le decisioni in “architettoniche” e “funzionali”. Le decisioni architettoniche (livelli, navigazione, DI) non sono coperte da YAGNI — sono necessarie per la manutenibilità. Le decisioni funzionali (funzionalità, screenshot, animazioni) — sono coperte.

Seguire ciecamente YAGNI quando si lavora con le API

Un altro estremo — ignorare i contratti API futuri. Uno sviluppatore riceve un JSON dal backend con 5 campi e ne analizza solo 3, perché “secondo YAGNI gli altri non sono necessari”. Il problema: quando viene aggiunto un campo, il backend potrebbe rompere l'analisi se la risposta è cambiata. La soluzione è mappare tutti i campi della risposta, anche se non tutti sono usati ora.

Secondo le Meta API Design Guidelines (2023), il client deve analizzare tutti i campi restituiti dal server, ignorando quelli non utilizzati, ma senza scartare l'intera struttura. YAGNI qui riguarda qualcos'altro: non aggiungere la gestione di campi che non sono ancora nella specifica “per precauzione nel caso il backend li restituisca”.

Analizza l'intera struttura della risposta (tutti i campi che il server restituisce attualmente). Non aggiungere la gestione di campi che non sono nella specifica API corrente. Questo è un equilibrio tra YAGNI e resilienza al cambiamento.