Autovalutazione dello studente

Questa lezione appartiene al Modulo 24 — Presentazione, valutazione e retrospettiva.

Il lavoro continua il progetto guida, il Registro del laboratorio scolastico. Questa lezione non aggiunge codice: ti chiede di fermarti e valutare onestamente ciò che hai imparato e ciò che ancora non padroneggi.

Obiettivo della lezione

Compilare una scheda di autovalutazione strutturata che copre i quattro livelli, la testabilità, la sostituibilità dell’archivio e la capacità di spiegare le scelte. La scheda non è decorativa — serve a identificare le lacune prima della presentazione finale.

Alla fine devi avere: una scheda compilata con risposte sì/no motivate e almeno un’area di miglioramento identificata.

Come usare questa scheda

Per ogni criterio, rispondi con:

• Sì — se puoi dimostrarlo con un file o un esempio del tuo progetto
• Parziale — se lo capisci ma non lo hai implementato bene nel progetto
• No — se è ancora una lacuna

Una risposta “Sì” senza un esempio concreto non vale. Ogni “Sì” deve avere una riga di prova: un file, una funzione, un test.

Procedura guidata

1. Apri il tuo progetto del Registro.
2. Per ogni criterio nella scheda, cerca il punto corrispondente nel codice.
3. Scrivi la risposta e l’esempio concreto nello stesso momento — non aspettare.
4. Per ogni “No” o “Parziale”, scrivi una riga su cosa faresti per migliorarlo.
5. Mostra la scheda al docente o al compagno di revisione prima della presentazione.

Attività in classe

Compila la scheda da solo, poi confronta con un compagno. Per ogni risposta diversa, spiegate a vicenda il ragionamento.

Spiegazione guidata per studiare

L’autovalutazione funziona solo se sei specifico. “Ho separato i livelli” non è una risposta utile. “Il file domain/strumento.js non importa nulla da infrastructure/ — posso mostrarlo” è una risposta utile.

I criteri sono organizzati nei quattro livelli del Registro. Per ognuno, la domanda guida è: puoi indicare un punto concreto del tuo progetto che lo dimostra?

Passo per passo nel progetto

Scorri la scheda completa e compila ogni sezione:

## Autovalutazione — Registro del laboratorio scolastico

### Livello Domain

Criterio 1: So spiegare cosa contiene domain/ e perché.
Risposta: sì / parziale / no
Prova concreta (file o funzione):

Criterio 2: Le regole di dominio (stato dello strumento, ciclo del prestito) sono in domain/ e non in altri livelli.
Risposta: sì / parziale / no
Prova concreta:

Criterio 3: Nessun file in domain/ importa da infrastructure/, presentation/ o application/.
Risposta: sì / parziale / no
Prova concreta:

### Livello Application

Criterio 4: Ogni caso d'uso fa una sola cosa: coordina, non decide le regole.
Risposta: sì / parziale / no
Prova concreta:

Criterio 5: I casi d'uso ricevono l'archivio come parametro (dependency injection) invece di importarlo direttamente.
Risposta: sì / parziale / no
Prova concreta:

Criterio 6: So spiegare la differenza tra registraStrumento (application) e creaStrumento (domain).
Risposta: sì / parziale / no
Spiegazione in una frase:

### Livello Infrastructure

Criterio 7: L'adapter localStorage ha le tre funzioni del contratto: caricaTutti, salva, trovaPerId.
Risposta: sì / parziale / no
Prova concreta:

Criterio 8: So sostituire l'adapter localStorage con uno in memoria senza toccare i casi d'uso.
Risposta: sì / parziale / no
Prova concreta (ho fatto questa sostituzione?):

Criterio 9: Le funzioni di mapping tra DTO e oggetti di dominio sono nell'adapter, non nel dominio.
Risposta: sì / parziale / no
Prova concreta:

### Livello Presentation

Criterio 10: I gestori di eventi nella UI chiamano solo casi d'uso — non contengono logica di business.
Risposta: sì / parziale / no
Prova concreta:

Criterio 11: I messaggi di errore mostrati all'utente sono in italiano e non espongono dettagli tecnici.
Risposta: sì / parziale / no
Esempio di messaggio usato:

### Testabilità

Criterio 12: Posso eseguire i casi d'uso senza aprire il browser — usando un archivio in memoria.
Risposta: sì / parziale / no
Ho un file di test o di verifica manuale?

Criterio 13: Ho almeno un test che verifica un caso limite: lista vuota, ID inesistente, strumento già in prestito.
Risposta: sì / parziale / no
Quale caso limite ho testato?

### Spiegabilità

Criterio 14: Posso spiegare la struttura del progetto in 2 minuti a qualcuno che non lo conosce.
Risposta: sì / parziale / no
Ho provato a farlo?

Criterio 15: Posso mostrare in diretta cosa succede quando cambio l'archivio (es. da localStorage a memoria).
Risposta: sì / parziale / no
Ho preparato questo scenario per la demo?

### Aree di miglioramento

Area 1 — cosa migliorerei se avessi altre 4 ore:

Area 2 — cosa ho capito solo alla fine e avrei voluto sapere prima:

Area 3 — quale scelta tecnica rifarei in modo diverso e perché:

Esempio JS — come dimostrare la sostituibilità dell’archivio

Un criterio comune di autovalutazione è: “posso cambiare l’archivio senza toccare i casi d’uso?”. Questo è come dimostrarlo concretamente:

// archivio-in-memoria.js (per il test)
let dati = [];

export function caricaTutti() { return [...dati]; }
export function salva(strumenti) { dati = [...strumenti]; }
export function trovaPerId(id) { return dati.find(s => s.id === id) ?? null; }

// test manuale senza browser
import * as archivio from "./archivio-in-memoria.js";
import { registraStrumento } from "./application/registraStrumento.js";

const s = registraStrumento({ nome: "Multimetro", categoria: "misura", ruolo: "responsabile" }, archivio);
console.log(archivio.caricaTutti()); // deve contenere il Multimetro

Se questo codice funziona senza errori, il criterio 12 è soddisfatto.

Prova di comprensione

Rispondi a queste domande prima di mostrare la scheda:

• Quale livello ti ha dato più difficoltà a capire e perché?
• Quale criterio ti ha sorpreso positivamente — lo soddisfacevi già senza saperlo?
• Se dovessi rifare il progetto da zero, cosa cambieresti nella struttura iniziale?
• C’è un criterio che hai segnato “Sì” ma che in realtà non sei sicuro di poter dimostrare?

Errori da evitare

• rispondere “Sì” senza indicare il file o la funzione concreta — non vale;
• saltare i criteri che fanno paura — sono esattamente quelli da affrontare;
• scrivere la scheda in fretta prima della presentazione invece di usarla per prepararsi;
• confondere “ho capito il concetto” con “l’ho implementato nel progetto”.

Prodotto da consegnare

La scheda compilata con tutte le 15 voci, le risposte motivate e almeno un esempio concreto per ogni “Sì”. Consegnala al docente prima della presentazione finale.

Checklist di chiusura

• tutti i 15 criteri hanno una risposta;
• ogni “Sì” ha almeno un file o una funzione di riferimento;
• almeno una area di miglioramento è descritta in modo specifico;
• ho confrontato la mia scheda con quella di un compagno;
• i “Parziale” e i “No” hanno un piano di azione, anche minimo.

Risultato atteso

Ho compilato la scheda con 15 criteri.
I miei "Sì" certi sono: [elenco].
I miei "Parziale" da migliorare sono: [elenco].
La mia area principale di miglioramento è: [una frase specifica].
Sono pronto alla presentazione perché: [una frase concreta].