KISS nello sviluppo mobile — cos’è, il principio di semplicità e come applicarlo

Cos’è KISS?

KISS (Keep It Simple, Stupid) è un principio di progettazione che richiede di minimizzare la complessità del sistema. È stato formulato nella Marina degli Stati Uniti negli anni ’60 dall’ingegnere Kelly Johnson (Lockheed SR-71 Blackbird). Johnson insisteva sul fatto che l’aereo dovesse essere riparabile da un meccanico sul campo senza strumenti speciali — questa è l’essenza di KISS.

Nello sviluppo software, KISS significa: una soluzione dovrebbe essere il più semplice possibile, ma non più semplice (la seconda parte della frase è attribuita ad Albert Einstein). La semplicità non è sinonimo di primitività; una soluzione semplice esegue il compito con ridondanza minima.

Uno studio di Google Research (2022) ha mostrato che il tempo medio di onboarding per un nuovo sviluppatore è di 3 settimane nei progetti che seguono KISS contro 10 settimane nei progetti con architettura eccessiva. Il codice semplice è un investimento nella velocità di adattamento dei nuovi membri del team.

Usa KISS come filtro: prima di aggiungere una nuova astrazione, chiediti “questo risolve un problema che esiste oggi, o un problema che potrebbe sorgere tra un anno?” Se è il secondo — non farlo.

KISS e il rasoio di Occam

Il rasoio di Occam (XIV secolo) è un principio filosofico: “le entità non devono essere moltiplicate senza necessità”. In programmazione, questo significa: di due soluzioni che soddisfano ugualmente i requisiti, scegli quella con meno entità (classi, moduli, dipendenze). KISS è l’implementazione pratica del rasoio di Occam nel codice.

La differenza è che il rasoio di Occam è un principio generale della conoscenza, mentre KISS è una pratica ingegneristica specifica con risultati misurabili: riduzione della complessità ciclomatica, meno righe di codice, tempi di revisione del codice più brevi. Le metriche consentono di valutare oggettivamente la conformità a KISS.

Segui questa metrica: il codice è considerato “sufficientemente semplice” se un nuovo sviluppatore comprende il frammento in un minuto senza commenti. Se serve più tempo — semplifica.

Perché la semplicità è cruciale nello sviluppo mobile?

Lo sviluppo mobile ha tre caratteristiche che rendono KISS particolarmente importante: risorse limitate del dispositivo (memoria, CPU), aggiornamenti frequenti delle piattaforme (iOS annualmente, Android trimestralmente) e la necessità di consegna rapida delle funzionalità tramite CI/CD. Il codice complesso non riesce a tenere il passo.

Un’analisi di Apple WWDC 2023: “Embrace Swift Generics” ha mostrato che il progetto iOS medio contiene 40–60% di “codice morto” — astrazioni scritte “per il futuro” che non vengono mai utilizzate. Questo codice non solo aumenta la dimensione del binario, ma rallenta anche la compilazione e complica la navigazione. KISS lo previene: scrivi solo ciò che serve ora.

Secondo il Android Developer Relations Report (2024), i progetti con un basso rapporto codice/test (meno di 1:0.8) hanno il 67% di bug in più in produzione. Il codice complesso è più difficile da testare — questa è una minaccia diretta alla qualità. La semplicità è un prerequisito per un’elevata copertura dei test.

Misura la complessità del tuo codice attraverso le metriche: complessità ciclomatica — mantieni ogni metodo sotto 10, idealmente sotto 5. Usa Detekt (Android) o SwiftLint (iOS) per la verifica automatizzata.

KISS contro overengineering: esempi pratici

Architettura eccessiva: troppi livelli

L’overengineering tipico è creare una factory astratta di repository in un progetto con un’unica fonte di dati. Invece di una semplice classe Repository, lo sviluppatore costruisce una catena: RepositoryFactory → IRepository → BaseRepository → RepositoryImpl — per la possibilità ipotetica di cambiare l’API in GraphQL.

Secondo il JetBrains Developer Survey (2023), il 43% degli sviluppatori Android ha ammesso di aver eliminato un livello architetturale durante il refactoring perché non è mai stato utilizzato. KISS dice: crea un’astrazione quando appare una seconda opzione di implementazione, non in previsione.

Inizia con un’implementazione concreta senza interfaccia. Quando appare una seconda fonte di dati — estrai l’interfaccia tramite refactoring (l’IDE lo farà automaticamente). È più veloce che scrivere un’interfaccia in anticipo.

Grafici di dependency injection eccessivamente complessi

I framework DI (Dagger, Hilt, Swinject) sono strumenti potenti, ma spesso provocano complessità. Gli sviluppatori creano un modulo separato per ogni entità, anche se utilizzata in un solo punto. Alternativa KISS: iniezione manuale tramite costruttore per casi semplici.

// Overengineering: modulo per un singolo repository
@Module
object UserModule {
    @Provides
    fun provideUserRepo(): UserRepository = UserRepositoryImpl()
}

// KISS: iniezione manuale se c’è un solo repository
class UserViewModel(
    private val repo: UserRepository = UserRepositoryImpl()
) { /* ... */ }

L’iniezione manuale nel costruttore è il pattern DI più semplice. Non richiede generazione di codice, annotazioni o moduli. Passa a un framework DI solo quando il progetto raggiunge 5+ schermate e l’iniezione manuale diventa difficile da mantenere.

Come applicare KISS in Android e iOS?

KISS in Android: ViewModel e LiveData semplici

Il ViewModel Android è una fonte frequente di complessità eccessiva. Gli sviluppatori aggiungono StateFlow, combine, flatMapLatest e catene di trasformazioni dove un semplice MutableLiveData con postValue sarebbe sufficiente. KISS raccomanda: inizia con la soluzione più semplice (LiveData), complica solo per un’esigenza specifica (reset dello stato, debounce).

// KISS: ViewModel semplice senza catene reattive
class ProfileViewModel : ViewModel() {
    private val _name = MutableLiveData<String>()
    val name: LiveData<String> = _name

    fun loadUser(id: String) {
        viewModelScope.launch {
            _name.postValue(repo.getUser(id).name)
        }
    }
}

In questo esempio, il ViewModel usa una coroutine per la richiesta asincrona, LiveData per pubblicare il risultato. Niente StateFlow, niente combine — solo ciò che è realmente necessario. Aggiungi StateFlow quando è richiesto un flusso di dati unidirezionale (UDF) con stato esplicito.

KISS in iOS: strutture semplici invece di classi

In iOS, il principio KISS si manifesta preferendo le strutture (struct) alle classi (class) per i modelli di dati. Le strutture sono tipi valore, non richiedono gestione della memoria tramite ARC e sono immutabili per impostazione predefinita. Le classi sono giustificate solo quando è necessaria identità (due riferimenti allo stesso oggetto) o ereditarietà.

// KISS: struct invece di class per il modello
struct User: Codable {
    let id: Int
    let name: String
    let email: String
}

// Overengineering: class con init e deinit manuali
class UserClass: NSObject {
    let id: Int
    init(id: Int) { self.id = id }
}

La struttura User ottiene automaticamente un init memberwise, conformità Equatable e Hashable (per tutti i campi), immutabilità e sicurezza in ambienti multithread. Una classe richiede init manuale, implementazione di NSObject ed è suscettibile a race condition attraverso lo stato condiviso.

Semplicità nel livello di rete

Il livello di rete è un’altra area in cui KISS viene spesso violato. Gli sviluppatori aggiungono una catena di Interceptor di 5+ elementi, serializzazione tramite factory astratte e mapper per ogni endpoint. Soluzione KISS: un URLSession con configurazione e una decodifica tramite Codable/JSON.

Secondo la Guida alla programmazione URLSession di Apple (2023), un semplice livello di rete con URLSession e Codable copre il 95% degli scenari delle app mobili. Le catene complesse di Interceptor sono necessarie solo per casi specifici: rinnovo dei token, logging, crittografia.

Inizia con un semplice livello di rete basato su URLSession + Codable. Aggiungi Interceptor quando sorgono esigenze reali, non “per precauzione”. Questo riduce il codice del livello di rete di 2–3 volte.

Errori tipici nel seguire KISS

Confondere semplicità e primitività

La semplicità non è la stessa cosa della primitività. Una soluzione semplice è una soluzione concisa e chiara che risolve il compito senza ridondanza. Una soluzione primitiva ignora le best practice e un’architettura solida. La differenza è che una soluzione semplice è facile da estendere, mentre una primitiva no.

Esempio: usare Activity come unica entità per tutti gli schermi è primitività, non semplicità. La semplicità è usare Navigation Component con Fragment diversi per schermi diversi, ma senza astrazioni inutili. KISS non giustifica un’architettura scadente.

Verifica te stesso: il tuo codice può cambiare quando aggiungi una nuova funzionalità? Se sì — la semplicità è corretta. Se ogni funzionalità richiede di riscrivere tutto — è primitività, refactoring immediato.

Ignorare i pattern in nome di KISS

I pattern (MVVM, MVI, Coordinator) non sono complicazione, ma strutturazione. KISS non vieta l’uso di pattern architetturali comprovati. Vieta il loro uso eccessivo: tre pattern dove uno basterebbe. Il giusto mezzo è un pattern architetturale per progetto e non più di 2–3 ausiliari (DI, Navigation).

Secondo il State of Mobile Architecture Report (2024), i progetti che usano esattamente un pattern architetturale hanno il 34% di bug in meno nel primo anno di sviluppo rispetto ai progetti “Frankenstein” che combinano 3+ pattern. Scegli MVVM o MVI per un progetto mobile — e mantienilo su tutti gli schermi.

Non mescolare MVVM e MVI nello stesso progetto. Se il team ha scelto MVVM — l’intero progetto deve seguire MVVM. Le eccezioni sono moduli di funzionalità individuali con la propria decisione architetturale, ma questa deve essere una scelta consapevole.