Checkpoint 40 ore: presentazione della versione completa

Questa lezione appartiene al Modulo 16 — Checkpoint finale.

Obiettivo della lezione

Preparare e condurre il checkpoint a 40 ore: una presentazione strutturata di 15 minuti del Registro del laboratorio scolastico, che copre il problema risolto, la demo live, le scelte architetturali, i test e una retrospettiva onesta.

Alla fine hai uno schema temporale preciso e una checklist pre-checkpoint da completare il giorno prima.

Perché serve nel percorso

Il checkpoint a 40 ore non è solo una valutazione — è la prova che il progetto è spiegabile, dimostrabile e difendibile. Saper presentare il proprio lavoro con esempi concreti è parte del percorso tanto quanto il codice.

Nel Registro del laboratorio

Struttura temporale della presentazione (15 minuti)

Minuti 0-2 — Apertura: il problema e la soluzione

Descrivi il problema in una frase e la soluzione in due:

"Il Registro del laboratorio scolastico tiene traccia degli strumenti,
dei prestiti e dei guasti in modo che docenti e tecnici possano sapere
in ogni momento quale strumento è disponibile, chi lo ha in prestito
e cosa è rotto.

È un'applicazione browser-only in JavaScript modulare, con localStorage
per la persistenza. Non usa framework — usa quattro livelli separati:
dominio, application, infrastruttura e presentazione."

Minuti 2-7 — Demo live

Esegui lo scenario nel browser in diretta. Lo scenario deve coprire almeno:

1. Registra uno strumento nuovo (“Multimetro”, categoria “Misura”).
2. Mostra che appare nella lista degli strumenti disponibili.
3. Registra un prestito per quello strumento.
4. Mostra che lo stato è cambiato a “in prestito”.
5. Prova a prestarlo di nuovo — mostra il messaggio di errore.
6. Chiudi il prestito.
7. Mostra che lo stato è tornato a “disponibile”.
8. Ricarica la pagina — mostra che i dati persistono.

Minuti 7-10 — Architettura

Mostra la struttura delle cartelle e spiega ogni livello con un esempio:

src/
  domain/       "Qui stanno le regole — per esempio, uno strumento guasto
                 non può essere prestato. Queste funzioni non sanno nulla
                 di localStorage o di HTML."

  application/  "Qui stanno i casi d'uso — registraPrestito, chiudiPrestito.
                 Ricevono l'archivio come dipendenza, non lo creano."

  infrastructure/ "Qui sta l'adapter di localStorage. Se domani si passa
                   a un'API, si sostituisce questo file senza toccare il dominio."

  presentation/ "Qui stanno i form handler e gli event listener. Leggono
                 l'input, chiamano il caso d'uso, mostrano il risultato."

Minuti 10-12 — Test

Esegui npm test in diretta e spiega due o tre test:

"Questo test verifica che uno strumento guasto non possa essere prestato.
Senza il test, potrei rompere questa regola per sbaglio durante il refactoring
e non me ne accorgerei."

[mostra l'output del runner con i test verdi]

Minuti 12-15 — Retrospettiva e prossimi passi

Sii onesto su cosa funziona, cosa no e cosa cambieresti:

"Cosa funziona bene: la separazione dei livelli — il dominio è testabile
senza il browser, e ho dimostrato che l'adapter si può sostituire senza
toccare i casi d'uso.

Cosa cambierei: avrei aggiunto i test prima di scrivere il codice, invece
che dopo. Alcuni casi limite li ho trovati tardi.

Prossimo passo: aggiungere la visualizzazione della cronologia dei prestiti
per strumento."

Procedura guidata

1. Prepara lo scenario di demo in anticipo — verifica che funzioni senza errori.
2. Prepara l’output di npm test — deve mostrare test verdi.
3. Scrivi l’apertura (problema + soluzione) in forma di testo da dire ad alta voce.
4. Prepara la spiegazione dei 4 livelli con un esempio per ognuno.
5. Prepara la retrospettiva con almeno una cosa che cambieresti.

Attività in classe

Compila la checklist pre-checkpoint il giorno prima della presentazione:

## Checklist pre-checkpoint a 40 ore

### Demo
[ ] lo scenario funziona senza errori nel browser
[ ] il messaggio di errore per strumento guasto appare correttamente
[ ] il messaggio di errore per doppio prestito appare correttamente
[ ] i dati persistono dopo ricaricamento della pagina
[ ] localStorage è pulito e contiene solo dati realistici (non dati di debug)

### Test
[ ] npm test esegue senza errori di configurazione
[ ] tutti i test passano (nessun test rosso)
[ ] l'output del runner è leggibile e mostra i nomi delle regole

### Codice
[ ] non ci sono console.log di debug nella console durante l'uso normale
[ ] nessun errore in console durante la demo
[ ] il README spiega come avviare il progetto

### Presentazione
[ ] ho scritto l'apertura (problema + soluzione in 2 minuti)
[ ] ho preparato la spiegazione dei 4 livelli con esempi
[ ] ho preparato la retrospettiva (cosa funziona, cosa cambierei, prossimo passo)
[ ] ho cronometrato la presentazione completa (deve stare in 15 minuti)

Spiegazione guidata per studiare

Il checkpoint a 40 ore valuta tre cose insieme: il codice, la comprensione e la comunicazione. Non basta avere un progetto funzionante — devi saper spiegare perché è fatto così.

La demo non è una demo del software — è una demo dell’architettura. Mentre mostri la demo, commenta le scelte:

"Quando clicco 'Presta', il form handler legge solo i valori dei campi
e chiama registraPrestito — non sa nulla di localStorage. È la separazione
tra presentazione e infrastruttura che rende possibile testare registraPrestito
senza il browser."

I test sono la tua assicurazione. Se durante la demo qualcosa non funziona, puoi dire: “questo scenario è coperto dal test X — mostrami dove si trova il problema.” I test ti danno sicurezza durante la presentazione.

La retrospettiva onesta vale più di una presentazione perfetta. Un “avrei aggiunto i test prima” è una risposta matura che dimostra comprensione del processo — non una debolezza.

Rispondere alle domande:

Quando il docente chiede “come mai hai scelto X invece di Y?”, la risposta deve avere questa struttura:

"Ho scelto X perché [motivo concreto nel contesto del Registro].
Y avrebbe richiesto [costo o complessità].
Il trade-off era [vantaggio X / svantaggio Y]."

Passo per passo nel progetto

1. Esegui la checklist pre-checkpoint completa.
2. Fai una prova della presentazione da solo — cronometra ogni sezione.
3. Se una sezione supera il tempo: taglia i dettagli, non la struttura.
4. Il giorno della presentazione: pulisci localStorage, esegui npm test, verifica lo scenario.
5. Durante la presentazione: parla lentamente, mostra il codice solo quando serve, non leggere il README.

Prova di comprensione

• Come si spiega in 2 minuti il problema che risolve il Registro?
• Come si dimostra durante la demo che i livelli sono separati davvero?
• Cosa dici se durante la demo appare un errore imprevisto?
• Come si risponde alla domanda “perché hai usato localStorage invece di un database?”

Errori da evitare

• iniziare la demo senza aver pulito localStorage — i dati di test sporcano la presentazione;
• non cronometrare la presentazione prima — 15 minuti si riempiono in fretta;
• mostrare il codice riga per riga invece di spiegare le scelte architetturali;
• non preparare la retrospettiva — la domanda “cosa cambieresti?” arriverà sempre.

Prodotto da consegnare

La checklist pre-checkpoint compilata con tutti i punti verificati, lo scenario di demo testato, e la struttura della presentazione scritta con i timing.

Checklist di chiusura

• la checklist pre-checkpoint è completa (tutti i punti spuntati)
• lo scenario di demo funziona senza errori
• npm test mostra tutti i test verdi
• la presentazione sta in 15 minuti (cronometrata)
• la retrospettiva è preparata con almeno una cosa concreta da cambiare
• localStorage è pulito e contiene solo dati realistici per la demo

Risultato atteso

Ho completato la checklist pre-checkpoint.
La demo funziona: registro strumento, presto, mostro errore per doppio prestito,
chiudo, verifico persistenza — tutto in 5 minuti.
npm test mostra 16 test verdi con nomi descrittivi.
La presentazione strutturata in 15 minuti è pronta e cronometrata.
Sono pronto per il checkpoint finale.