Trasformare la revisione in una lista di azioni

Questa lezione appartiene al Modulo 21 — Usare l’AI come revisore.

Obiettivo della lezione

Trasformare il feedback qualitativo di una revisione del codice — da un docente, da un compagno o da un AI — in una lista di azioni concrete, ordinate per priorità, con file e riga di riferimento.

Alla fine non hai “commenti da leggere” ma “azioni da fare” con una sequenza chiara.

Perché serve nel percorso

Il feedback di una revisione spesso arriva come osservazioni generali: “la funzione fa troppo”, “manca la gestione degli errori”, “il dominio dipende dall’infrastruttura”. Queste osservazioni sono corrette ma non azionabili — non dicono dove intervenire, in quale ordine, e come verificare che sia fatto.

Nel Registro del laboratorio

Feedback tipico di revisione (non azionabile):

- La funzione registraPrestito sembra fare troppe cose.
- Manca la gestione degli errori in alcuni punti.
- La UI legge localStorage direttamente.
- Non ci sono test per i casi limite.
- Il README non spiega come avviare il progetto.

Lista di azioni risultante (azionabile):

Priorità	Azione	File	Riga	Verifica
Alta	Iniettare archivio come dipendenza in registraPrestito	src/application/registraPrestito.js	1-30	test passa senza localStorage
Alta	Aggiungere try/catch intorno a JSON.parse negli adapter	src/infrastructure/archivioStrumentiLocalStorage.js	8, 20	test con dato corrotto non crasha
Media	Rimuovere localStorage.getItem dalla UI	src/presentation/paginaPrestiti.js	15	nessun import localStorage nella UI
Media	Aggiungere test per strumento in manutenzione	test/application/registraPrestito.test.js	—	test fallisce poi passa
Bassa	Aggiornare README con istruzioni di avvio	README.md	—	si legge in 2 minuti

Come costruire la tabella:

Per ogni osservazione del feedback:

1. Azione: verbo + cosa fare (iniettare, aggiungere, rimuovere, spostare, aggiornare).
2. Priorità: Alta (blocca funzionamento o test), Media (migliora architettura), Bassa (stile o documentazione).
3. File: percorso relativo del file da modificare.
4. Riga: numero approssimativo o intervallo.
5. Verifica: come sai che è fatto (test, grep, lettura).

Procedura guidata

1. Leggi il feedback completo senza agire.
2. Per ogni osservazione: scrivi un’azione con verbo specifico.
3. Identifica il file e la riga di riferimento (apri il codice se necessario).
4. Assegna la priorità con il criterio: Alta = blocca qualcosa, Media = migliora struttura, Bassa = stile/doc.
5. Ordina le azioni: prima le Alta, poi le Media, poi le Bassa.
6. Esegui le azioni una alla volta, segnando quella completata.

Attività in classe

Trasforma questo feedback in una lista di azioni:

Revisione del Registro del laboratorio:

"Ho notato che la funzione chiudiPrestito legge direttamente da localStorage invece di
ricevere l'archivio come parametro. Questo rende difficile testarla.

Inoltre, il messaggio di errore 'PRESTITO_GIA_CHIUSO' appare direttamente nella pagina
invece di essere tradotto in italiano.

Manca un README che spieghi come popolare i dati iniziali per testare l'applicazione.

I test esistenti non coprono il caso in cui si chiude un prestito con ID non valido."

## Lista di azioni dalla revisione

| Priorità | Azione | File | Riga | Verifica |
| --- | --- | --- | --- | --- |
| | | | | |
| | | | | |
| | | | | |
| | | | | |

Spiegazione guidata per studiare

La differenza tra un’osservazione e un’azione:

Osservazione	Azione
”La funzione fa troppo"	"Estrai verificaPrestabilità come funzione separata in src/domain/strumento.js"
"Manca gestione errori"	"Aggiungi try/catch intorno a JSON.parse in archivioStrumentiLocalStorage.js riga 8"
"La UI accede a localStorage"	"Rimuovi localStorage.getItem dalla riga 15 di paginaPrestiti.js e usa l’archivio iniettato"
"Non ci sono test"	"Aggiungi test per STRUMENTO_IN_MANUTENZIONE in test/application/registraPrestito.test.js”

Un’azione ben scritta risponde a: cosa faccio, dove, e come so che è fatto.

Criteri di priorità per il Registro:

• Alta: l’azione risolve un problema che causa errori visibili o impedisce di testare il codice.
• Media: l’azione migliora la struttura del progetto (confini tra livelli, dipendenze).
• Bassa: l’azione migliora leggibilità, stile o documentazione.

L’ordine di esecuzione: prima le Alta (fissano il funzionamento), poi le Media (migliorano la struttura per la presentazione), poi le Bassa (finiture).

Verifica di completamento: ogni azione deve avere una verifica misurabile:

Azione: inietta archivio in chiudiPrestito
Verifica: il test test/application/chiudiPrestito.test.js passa senza aprire il browser

Azione: traduci PRESTITO_GIA_CHIUSO in italiano
Verifica: grep "PRESTITO_GIA_CHIUSO" src/presentation/ restituisce zero risultati

Passo per passo nel progetto

1. Raccogli tutto il feedback (dal docente, dall’AI, da un compagno).
2. Copia ogni osservazione e trasformala in un’azione con verbo specifico.
3. Apri il codice e identifica file e riga per ogni azione.
4. Assegna la priorità con i criteri Alta/Media/Bassa.
5. Ordina la tabella per priorità.
6. Esegui le azioni nell’ordine, segnando ogni completamento con la verifica.

Prova di comprensione

• Qual è la differenza tra un’osservazione e un’azione verificabile?
• Come decidi se un’azione ha priorità Alta o Media?
• Perché è utile avere una verifica specifica per ogni azione?
• Come gestisci azioni in conflitto (due modifiche allo stesso file)?

Errori da evitare

• eseguire le azioni nell’ordine in cui appaiono nel feedback invece che per priorità;
• trasformare l’osservazione in un’azione vaga (“migliorare la funzione X”);
• dimenticare la verifica — senza di essa non sai quando l’azione è davvero completata;
• aprire tutti i file contemporaneamente invece di completare un’azione alla volta.

Prodotto da consegnare

La tabella delle azioni compilata con priorità, file, riga e verifica, e almeno le prime tre azioni Alta eseguite e verificate.

Checklist di chiusura

• ogni osservazione del feedback è diventata un’azione con verbo specifico
• ogni azione ha un file e una riga di riferimento
• ogni azione ha una verifica misurabile
• la tabella è ordinata per priorità (Alta prima)
• le azioni Alta sono state eseguite e verificate prima delle Media

Risultato atteso

Ho trasformato il feedback della revisione in 6 azioni concrete nella tabella.
Le 2 azioni Alta (iniettare archivio, tradurre errori) sono state eseguite e verificate.
Le 3 azioni Media (aggiungere test, spostare regole) sono pianificate per la prossima sessione.
L'azione Bassa (README) è in coda.
Ogni azione completata ha la sua verifica documentata.