Valutazione con rubrica

Questa lezione appartiene al Modulo 23 — Preparare la presentazione.

Obiettivo della lezione

Comprendere i criteri con cui il Registro del laboratorio scolastico viene valutato, saper autovalutare il proprio progetto con la rubrica prima della presentazione, e capire cosa distingue ogni livello di valutazione.

Perché serve nel percorso

Conoscere la rubrica prima della presentazione ti permette di concentrare il lavoro sulle aree che contano di più — e di autovalutarti onestamente invece di scoprire le lacune durante la revisione.

Nel Registro del laboratorio

La rubrica valuta cinque aree principali del progetto.

Area 1 — Separazione dei livelli (dominio, application, infrastructure, presentation)

Livello	Descrittore
Insufficiente	I livelli non esistono o sono nominali: tutto il codice è in un file o la logica di dominio è nella UI.
Sufficiente	I livelli esistono come cartelle, ma ci sono dipendenze inverse (es. dominio che importa da infrastructure).
Buono	I livelli sono separati e le dipendenze vanno nella direzione corretta. Qualche dipendenza non ideale ma non strutturale.
Ottimo	I confini sono netti, le dipendenze sono iniettate, il dominio è testabile senza il browser.

Area 2 — Regole di dominio

Livello	Descrittore
Insufficiente	Le regole (strumento guasto, prestito già chiuso) non esistono o sono disperse nella UI.
Sufficiente	Le regole esistono ma stanno nel posto sbagliato (nel form handler, nell’adapter).
Buono	Le regole stanno nel dominio o nel caso d’uso, con errori espliciti e leggibili.
Ottimo	Le regole hanno codici errore semantici, sono testabili in isolamento, non dipendono da localStorage o DOM.

Area 3 — Test

Livello	Descrittore
Insufficiente	Nessun test automatico o test che non verificano nulla di reale.
Sufficiente	Almeno 3 test che coprono il caso felice di un caso d’uso.
Buono	Test per ogni caso d’uso principali, inclusi alcuni casi di errore. I test usano fake repository.
Ottimo	Test per tutti i casi d’uso, per i casi limite, per il mapping. I test hanno nomi descrittivi. L’output del runner è leggibile.

Area 4 — Documentazione

Livello	Descrittore
Insufficiente	Nessun README o README copiato dal template senza modifiche.
Sufficiente	README con titolo, descrizione e istruzioni di avvio.
Buono	README con struttura del progetto, spiegazione dei livelli, istruzioni complete.
Ottimo	README completo, diagramma dei livelli, spiegazione delle scelte architetturali con motivazioni.

Area 5 — Presentazione e comunicazione

Livello	Descrittore
Insufficiente	La presentazione descrive il codice senza spiegare le scelte. Non c’è demo funzionante.
Sufficiente	La demo funziona per il caso principale. Le scelte sono descritte ma non motivate.
Buono	La demo copre almeno 2 scenari. Le scelte architetturali sono motivate con esempi dal codice.
Ottimo	La demo copre casi felici e casi di errore. Le scelte sono motivate, i limiti sono riconosciuti, il prossimo passo è indicato.

Procedura guidata

Usa la rubrica per autovalutarti prima della presentazione:

1. Per ogni area: leggi i quattro descrittori.
2. Scegli il livello che descrive meglio il tuo progetto adesso.
3. Identifica cosa ti manca per salire di un livello.
4. Prioritizza le aree dove sei più lontano dal livello desiderato.

Attività in classe

Compila questa scheda di autovalutazione:

## Autovalutazione con rubrica

Area 1 — Separazione dei livelli
Livello attuale: insufficiente / sufficiente / buono / ottimo
Evidenza: (cosa nel codice dimostra questo livello)
Per salire: (cosa devo fare)

Area 2 — Regole di dominio
Livello attuale:
Evidenza:
Per salire:

Area 3 — Test
Livello attuale:
Evidenza:
Per salire:

Area 4 — Documentazione
Livello attuale:
Evidenza:
Per salire:

Area 5 — Presentazione
Livello attuale:
Evidenza:
Per salire:

Spiegazione guidata per studiare

La rubrica serve anche per capire cosa NON conta nella valutazione:

• la quantità di codice scritto (un progetto piccolo ben strutturato vale più di uno grande e disorganizzato);
• l’uso di framework o librerie avanzate (il progetto è JavaScript modulare puro);
• la perfezione (un livello “buono” su tutti i criteri è un ottimo risultato).

Conta invece:

• la chiarezza delle scelte e la capacità di motivarle;
• la presenza di test che proteggono comportamenti reali;
• la separazione effettiva dei livelli, dimostrabile durante la demo.

Come dimostrare il livello “ottimo” in Area 1 durante la presentazione:

Mostra che puoi sostituire l’adapter di localStorage con uno in memoria senza toccare i casi d’uso:

// Adapter reale (src/infrastructure/archivioStrumentiLocalStorage.js)
// Adapter in memoria per i test (test/fakes/archivioStrumentiFake.js)
// Il caso d'uso registraPrestito funziona con entrambi — non sa la differenza

Questa è la prova concreta che il confine è reale, non solo nominale.

Come dimostrare il livello “ottimo” in Area 3:

Esegui i test davanti al docente e spiega per ogni test quale regola protegge:

"Questo test verifica che uno strumento guasto non possa essere prestato.
Se rimuovessi questo controllo da registraPrestito, il test fallirebbe."

Passo per passo nel progetto

1. Completa la scheda di autovalutazione.
2. Identifica le due aree con il divario maggiore tra livello attuale e livello desiderato.
3. Per ogni area: elenca le tre azioni concrete che aumentano il livello.
4. Prioritizza le azioni in base al tempo disponibile.
5. Esegui le azioni e rivaluta.

Prova di comprensione

• Qual è la differenza tra livello “sufficiente” e “buono” per i test?
• Come si dimostra durante la presentazione che i livelli sono separati davvero?
• Cosa manca al tuo progetto per salire da “buono” a “ottimo” in Area 2?
• Perché la quantità di codice non è un criterio di valutazione?

Errori da evitare

• autovalutarsi troppo generosamente senza evidenza nel codice;
• concentrare tutto il tempo sull’Area 5 (presentazione) trascurando le aree tecniche;
• pensare che un README lungo valga di più di uno chiaro e preciso;
• presentare senza aver eseguito i test — potrebbero fallire per un bug recente.

Prodotto da consegnare

La scheda di autovalutazione compilata con evidenze concrete per ogni area e le azioni pianificate per migliorare le aree più deboli prima della presentazione.

Checklist di chiusura

• ogni area è valutata con un livello e un’evidenza concreta dal codice
• le azioni di miglioramento sono specifiche (non “migliorare i test” ma “aggiungere test per chiudiPrestito”)
• le aree più deboli hanno più azioni di miglioramento
• la scheda è onesta — non ottimistica
• il piano è realistico rispetto al tempo disponibile

Risultato atteso

Ho compilato la scheda di autovalutazione per tutte e 5 le aree.
Area 1 (livelli): buono — ho la struttura ma un'importazione diretta da rimettere a posto.
Area 2 (regole): ottimo — tutte le regole sono nel dominio con codici errore.
Area 3 (test): sufficiente — ho 4 test, mancano i casi di errore.
Area 4 (docs): sufficiente — il README c'è ma manca la spiegazione dei livelli.
Area 5 (presentazione): buono — la demo funziona, devo preparare anche un caso di errore.
Azioni prioritarie: aggiungere test di errore, aggiornare il README.