Architettura dell'applicazione: fondamenti sugli errori comuni

Un'applicazione può essere bella esteriormente, ma se l'architettura interna è pessima, sarà lenta, difficile da mantenere e piena di bug. Architettura software definisce il modo in cui le parti del codice sono organizzate e comunicano tra loro. È il fondamento dell'edificio.

Se stai avviando o hai ereditato un progetto legacy, comprendi i fondamenti in modo da non costruire un castello di carte.

Cos'è la buona architettura?

Una buona architettura dovrebbe essere:

Scalabile: è facile aggiungere nuove funzionalità senza interrompere quelle vecchie.
Testabile: facile da scrivere test automatizzati.
Manutenibile: qualsiasi nuovo sviluppatore dovrebbe comprendere rapidamente il codice.

Standard comuni (zuppa alfabetica)

MVC (controller di visualizzazione del modello)

Il classico.

Modello: Dati.
Visualizza: schermo.
Controller: Logica che collega i due.
Problema: Nelle app mobili, il Controller tende a diventare gigantesco (Massive View Controller), concentrando troppe responsabilità.

MVVM (Modello-Vista-VistaModello)

Il moderno standard di settore (Android Jetpack, iOS Swift UI).

ViewModel: prepara i dati specificatamente per la visualizzazione da visualizzare. La vista "osserva" il ViewModel. Se i dati cambiano, lo schermo si aggiorna (Reattività).
Vantaggio: Separa molto bene la logica dall'interfaccia.

Architettura pulita

Proposto da Robert C. Martin (zio Bob). Divide l'app in livelli (cipolla).

Core (Dominio): pure regole aziendali (non sanno che è un'app).
Dati: repository, API, database.
Presentazione: interfaccia utente, ViewModels. La regola è: gli strati all'esterno conoscono gli strati all'interno, ma gli strati all'interno NON conoscono gli strati all'esterno. Il Core non sa se funziona su un iPhone o su un forno a microonde.

Errori fondamentali

Logica nell'interfaccia utente: inserisci le regole aziendali ("se saldo < 0, coloralo di rosso") direttamente nel file dello schermo. Ciò rende impossibile eseguire il test senza eseguire l'emulatore.
Accoppiamento forte: se modifichi la libreria API (Retrofit) e devi riscrivere le schermate, l'accoppiamento è sbagliato. Utilizzare l'inserimento delle dipendenze.
God Objects: classi che fanno tutto (chiamare API, salvare nel database, formattare i dati). Suddividersi in piccole classi con un'unica responsabilità (SOLID).

Conclusione

Non esiste “l’architettura perfetta”, esiste l’architettura adeguata alla dimensione del progetto. Per un MVP, andrà bene il semplice MVC. Per una Super App, l'architettura pulita è obbligatoria. L’importante è scegliere uno standard e seguirlo con coerenza.