Elencare cosa migliorare in futuro

Questa lezione appartiene al Modulo 23 — Revisione finale.

Il lavoro continua il progetto guida, il Registro del laboratorio scolastico. In questa lezione costruisci una lista ragionata di miglioramenti futuri — non un elenco di desideri, ma un’analisi concreta con priorità e impatto sull’architettura.

Obiettivo della lezione

Compilare una lista di almeno cinque miglioramenti futuri per il Registro, ognuno con una descrizione del problema che risolve, la priorità (alta/media/bassa) e l’impatto architetturale (quale livello cambierebbe).

Alla fine devi avere: una sezione “Miglioramenti futuri” nel README con almeno cinque voci strutturate.

Come ragionare sui miglioramenti futuri

Un miglioramento futuro utile ha tre caratteristiche:

• risolve un problema reale o una limitazione dell’implementazione attuale
• ha un impatto architetturale chiaro (quale livello cambia?)
• ha una priorità motivata (perché adesso non è necessario?)

Un miglioramento che non ha questi tre elementi non è un piano — è un desiderio. “Sarebbe bello avere un’app mobile” non è un miglioramento futuro utile per il Registro scolastico.

I miglioramenti più rilevanti per il Registro

Questi sono i miglioramenti futuri più naturali per il Registro del laboratorio, in ordine di impatto architetturale crescente:

1. Persistenza su database o file JSON (bassa complessità architetturale)

Problema attuale: i dati vivono solo nel browser dell’utente. Se l’utente cambia browser o cancella i dati, tutto viene perso. Non c’è condivisione tra più utenti.

Soluzione futura: sostituire l’adapter localStorage con un adapter che usa un server con database (SQLite, PostgreSQL) o file JSON gestito da Node.js.

Impatto architetturale: solo il livello Infrastructure cambia. Domain e Application rimangono invariati — questa è la prova che l’architettura a livelli ha funzionato.

Priorità: media — per un laboratorio reale con più utenti, questo è il passo successivo naturale.

2. Autenticazione degli utenti (media complessità)

Problema attuale: chiunque apra il browser può fare qualsiasi operazione. Non c’è distinzione tra studente, tecnico e responsabile (se non la costante RUOLO_CORRENTE in main.js).

Soluzione futura: aggiungere un sistema di login con JWT o sessioni. Il ruolo viene letto dal token di autenticazione invece di essere impostato manualmente.

Impatto architetturale: si aggiunge un adapter di autenticazione in Infrastructure; la funzione puoEseguire in Application usa il ruolo dal token invece del parametro; la Presentation mostra il login.

Priorità: alta per uso reale, bassa per uso scolastico — dipende dal contesto.

3. Transazioni atomiche (alta complessità)

Problema attuale: apriPrestito fa due operazioni in sequenza: aggiorna lo strumento e crea il prestito. Se la seconda operazione fallisce dopo la prima, i dati sono in uno stato inconsistente (strumento “in-prestito” senza prestito corrispondente).

Soluzione futura: usare transazioni a livello database per garantire che le due operazioni siano atomiche (tutte e due o nessuna).

Impatto architetturale: richiede un adapter che supporti transazioni; i casi d’uso devono passare l’operazione all’adapter in modo transazionale; LocalStorage non supporta transazioni — questo miglioramento richiede necessariamente un database.

Priorità: bassa con localStorage (impossibile), alta con un database reale.

4. Notifiche e alert (bassa complessità)

Problema attuale: non c’è modo di sapere quando uno strumento è stato restituito in ritardo o quando un guasto è rimasto non risolto per troppo tempo.

Soluzione futura: aggiungere un controllo periodico che identifica prestiti scaduti e guasti non risolti, e mostra notifiche all’utente.

Impatto architetturale: si aggiunge un caso d’uso verificaScadenze in Application; la Presentation riceve un meccanismo di notifica (es. setInterval); il dominio aggiunge il concetto di “scadenza”.

Priorità: media — utile ma non bloccante per l’uso del laboratorio.

5. Storico completo e audit log (media complessità)

Problema attuale: i prestiti chiusi sono visibili nell’array prestiti, ma non c’è un log delle operazioni (chi ha segnalato il guasto, quando è stato restituito uno strumento, chi ha modificato lo stato).

Soluzione futura: aggiungere un archivio di eventi (event log) che registra ogni operazione con timestamp e tipo.

Impatto architetturale: si aggiunge archivioEventi in Infrastructure; ogni caso d’uso scrive un evento oltre alle modifiche normali; si aggiunge un caso d’uso leggiStorico in Application.

Priorità: bassa — utile per audit ma non necessario per le funzionalità base.

Procedura guidata

1. Apri il README del Registro.
2. Scrivi la sezione “Miglioramenti futuri”.
3. Per ogni miglioramento: problema attuale, soluzione futura, impatto architetturale, priorità.
4. Ordina i miglioramenti per priorità.
5. Indica esplicitamente quali miglioramenti richiedono cambiamenti architetturali profondi e quali sono sostituzioni di adapter.

Attività in classe

Prima di scrivere, identifica i limiti attuali del tuo Registro specifico — potrebbero essere diversi da quelli dell’elenco sopra:

## Limiti attuali del mio Registro

Limite 1 (cosa non funziona o manca):
Miglioramento corrispondente:
Livello che cambierebbe:

Limite 2:
Miglioramento:
Livello:

[...]

Spiegazione guidata per studiare

La lista dei miglioramenti futuri non è una lista di rimpianti. È una dimostrazione di comprensione: sai cosa hai costruito, sai cosa manca, sai quali sarebbero le conseguenze architetturali di ogni aggiunta.

Un aspetto importante: alcuni miglioramenti si integrano naturalmente nell’architettura esistente (sostituire l’adapter — solo Infrastructure cambia), altri richiedono cambiamenti profondi in più livelli (aggiungere l’autenticazione — tocca tutti i livelli). Distinguere questi due tipi dimostra che hai capito come le dipendenze funzionano nel sistema.

Passo per passo nel progetto

1. Scrivi la sezione nel README. Usa questa struttura per ogni voce:

### [Nome del miglioramento]

Problema attuale: [una frase]
Soluzione futura: [una frase]
Livelli coinvolti: [Infrastructure / Application / Domain / Presentation / tutti]
Priorità: alta / media / bassa
Motivo della priorità: [una frase]

1. Per il miglioramento “persistenza su database”, aggiungi una nota specifica:

### Persistenza su database

Problema attuale: i dati vivono solo nel localStorage del browser dell'utente.
Soluzione futura: adapter verso SQLite o PostgreSQL con Node.js.
Livelli coinvolti: solo Infrastructure — domain e application non cambiano.
Priorità: media.
Motivo: per uso con più utenti contemporanei, localStorage non è sufficiente.
Nota architetturale: questo miglioramento dimostra che l'architettura a livelli
ha funzionato — cambiare la persistenza non richiede toccare le regole di business.

Prova di comprensione

Rispondi per iscritto:

• Quale miglioramento futuro hai già parzialmente implementato nel tuo Registro?
• Quale miglioramento richiederebbe di toccare il livello Domain? Perché?
• Se il docente chiede “perché non hai implementato l’autenticazione?”, qual è la risposta architettural corretta?
• Qual è la differenza tra un miglioramento che tocca solo Infrastructure e uno che tocca tutti i livelli?

Errori da evitare

• elencare miglioramenti senza spiegare quale problema risolvono;
• non indicare l’impatto architetturale — è la parte più interessante per il docente;
• mescolare miglioramenti tecnici (database) con miglioramenti funzionali (notifiche) senza distinguerli;
• presentare i limiti come fallimenti invece che come scelte consapevoli di scope.

Prodotto da consegnare

La sezione “Miglioramenti futuri” nel README con almeno cinque voci strutturate. Come verifica: mostrala al docente e spiega verbalmente il perché della priorità assegnata a ciascuna.

Checklist di chiusura

• almeno cinque miglioramenti sono elencati con problema, soluzione e livello coinvolto;
• ogni miglioramento ha una priorità motivata;
• almeno un miglioramento tocca solo Infrastructure (dimostrando la sostituibilità);
• almeno un miglioramento richiede cambiamenti in più livelli (dimostrando la complessità);
• la sezione è nel README e leggibile senza spiegazioni aggiuntive.

Risultato atteso

Ho elencato 5 miglioramenti futuri per il Registro.
Il miglioramento prioritario è: [nome] — perché: [motivazione].
Il miglioramento più semplice architetturalmente è: [nome] — tocca solo Infrastructure.
Il più complesso è: [nome] — richiede cambiamenti in tutti i livelli.
La sezione è nel README con priorità e impatto per ogni voce.