Prima retrospettiva: cosa funziona e cosa fa paura cambiare

Abbiamo costruito un Registro fragile.

Questo non è un fallimento. È il risultato previsto del modulo.

Ora dobbiamo fermarci e guardare il progetto con lucidità:

• cosa funziona?
• cosa è già utile?
• cosa fa paura cambiare?
• quali regole non devono restare nella UI?
• quali problemi guideranno il prossimo refactoring?

La retrospettiva serve a trasformare una sensazione di disordine in una lista di problemi concreti.

Obiettivo della lezione

Alla fine devi avere:

• una lista dei comportamenti che funzionano;
• una lista delle fragilità osservate;
• una lista delle modifiche che oggi fanno paura;
• un primo backlog architetturale;
• una prima ipotesi di responsabilità;
• una frase personale sul perché il programma fragile è stato utile.

Questa è una lezione breve, ma importante: prima di cambiare struttura, decidiamo che cosa vogliamo proteggere.

Cosa funziona

Prima di criticare il codice, riconosci cosa funziona.

Esempi:

• la pagina mostra gli strumenti;
• la ricerca restituisce risultati;
• il filtro per stato funziona;
• gli stati cambiano;
• il prestito viene registrato;
• lo strumento guasto viene bloccato;
• alcuni dati possono essere salvati;
• l’utente vede messaggi.

Questa lista è importante: quando faremo refactoring, dovremo preservare questi comportamenti.

Il refactoring non deve cancellare ciò che funziona. Deve rendere il codice più modificabile mantenendo il comportamento visibile.

Cosa è fragile

Ora scrivi cosa è fragile.

Esempi:

• troppe responsabilità in main.js;
• regole importanti dentro event listener;
• stati scritti come stringhe duplicate;
• salvataggio mescolato alla UI;
• dati modificati direttamente;
• funzioni difficili da testare;
• errori tecnici possibili;
• cambio stato troppo libero;
• localStorage usato nello stesso punto in cui si leggono input e si mostrano messaggi.

Questa lista non è una colpa. È una mappa di lavoro.

Una fragilità ben descritta è già metà del refactoring.

Cosa fa paura cambiare

Una domanda molto utile è:

quale modifica mi farebbe paura fare adesso?

Possibili risposte:

• aggiungere un nuovo stato;
• cambiare il modo di salvare i dati;
• creare una seconda interfaccia;
• scrivere test automatici;
• modificare le regole di prestito;
• impedire passaggi di stato non validi;
• separare messaggi utente e dettagli tecnici;
• cambiare i nomi degli stati senza rompere filtri e controlli.

Se una modifica fa paura, probabilmente c’è un confine architetturale poco chiaro.

Non vuol dire che il codice sia da buttare. Vuol dire che abbiamo trovato un punto da separare con calma.

Cosa non fare ancora

Non riscrivere tutto.

Non creare dieci cartelle nuove solo per sentirti ordinato.

Non introdurre un framework.

Non trasformare subito ogni funzione in una classe.

Non cercare pattern avanzati.

Il prossimo passo non è “fare architettura grande”. È capire le responsabilità e separare una cosa alla volta.

Preparare il backlog architetturale

Nel file note-architettura.md aggiungi:

## Backlog architetturale

- spostare le regole di prestito fuori dalla UI;
- definire gli stati ammessi in un punto solo;
- separare ricerca e render;
- separare salvataggio e logica applicativa;
- rendere testabile la regola "uno strumento guasto non può essere prestato";
- trasformare errori tecnici in messaggi utente;
- ridurre le dipendenze globali dentro le funzioni.

Questo backlog non è una lista di cose da fare subito. È una direzione.

Nel percorso successivo non sistemeremo tutto in una volta. Sceglieremo piccoli passi.

Da fragilità ad attività

Una fragilità non deve restare una lamentela generica.

Deve diventare un’attività osservabile.

Esempio:

Osservazione	Perché è un problema	Possibile attività
La regola del prestito è nell’event listener	Non posso testarla senza aprire la pagina	Creare una funzione separata per verificare se lo strumento è prestabile
Gli stati sono stringhe ripetute	Un errore di scrittura rompe filtri e controlli	Definire gli stati in un punto solo
Il salvataggio è dentro la funzione che disegna la pagina	Cambiare persistenza diventa rischioso	Spostare lettura e scrittura in funzioni dedicate
I messaggi tecnici arrivano all’utente	L’utente non capisce cosa deve fare	Tradurre gli errori in messaggi comprensibili
I dati vengono modificati da più punti	È difficile capire chi cambia cosa	Far passare le modifiche da casi d’uso espliciti

Questa tabella è il ponte tra il programma fragile e l’architettura.

Non dice ancora come sarà la soluzione finale. Dice quali problemi meritano attenzione.

Prima ipotesi di responsabilità

Scrivi una prima ipotesi:

## Prime responsabilità individuate

- UI: leggere input, mostrare risultati e messaggi.
- Regole: decidere se uno strumento può essere prestato.
- Casi d'uso: coordinare prestito, restituzione, ricerca e segnalazioni.
- Persistenza: salvare e leggere strumenti e prestiti.

Questa ipotesi verrà raffinata. Per ora serve a preparare il terreno.

Stiamo iniziando a vedere quattro aree:

• Presentation;
• Application;
• Domain;
• Infrastructure.

Non servono ancora come etichette da mettere ovunque. Servono come modo per ragionare.

Esempio di retrospettiva compilata

Un possibile estratto potrebbe essere questo:

## Funziona

- riesco a registrare uno strumento;
- riesco a cercarlo per nome;
- riesco a cambiare lo stato;
- riesco a registrare un prestito;
- il programma impedisce alcuni casi sbagliati.

## È fragile

- la UI conosce troppi dettagli degli strumenti;
- la regola "non prestare strumenti guasti" è mescolata al click del pulsante;
- localStorage viene usato nello stesso file del render;
- gli stati sono scritti come testo libero;
- non so testare un prestito senza usare il browser.

## Fa paura cambiare

- aggiungere lo stato "in manutenzione";
- passare da localStorage a JSON;
- creare una seconda schermata;
- cambiare la struttura dei dati salvati;
- distinguere errori utente ed errori tecnici.

Questo esempio non va copiato in modo automatico.

Serve a capire il livello di concretezza richiesto: ogni frase deve riferirsi a un punto reale del progetto.

Errore tipico

Un errore frequente è scrivere frasi troppo generiche:

Il codice è confuso.

Questa frase è vera, ma non aiuta.

Meglio:

La funzione che gestisce il click su "Registra prestito" legge gli input,
cerca lo strumento, controlla lo stato, modifica l'array, salva i dati e
aggiorna la pagina.

La seconda frase permette di agire.

Da lì possiamo decidere cosa separare prima.

Attività guidata

Completa tre liste:

## Funziona

## È fragile

## Fa paura cambiare

Ogni lista deve avere almeno cinque elementi.

Poi scegli i tre problemi più importanti da affrontare nei moduli successivi.

Esempio:

## Tre problemi prioritari

1. Le regole di prestito sono dentro la UI.
2. Gli stati sono stringhe duplicate.
3. Il salvataggio è mescolato agli event listener.

La priorità non deve essere perfetta. Deve essere motivata.

Micro-sfida

Scrivi una frase che spieghi perché il programma fragile è stato utile.

Esempio:

Il programma fragile è stato utile perché ci ha fatto vedere che la UI stava
decidendo regole, modificando dati e salvando informazioni nello stesso punto.

La frase deve essere tua. Non deve suonare da manuale.

Vincolo: deve contenere almeno due parole tra UI, regole, dati, salvataggio, test, stati.

Prodotto da ottenere

Alla fine della lezione devi avere:

• sezione Funziona compilata;
• sezione È fragile compilata;
• sezione Fa paura cambiare compilata;
• backlog architetturale iniziale;
• prime responsabilità individuate;
• tre problemi prioritari;
• frase personale sulla funzione didattica del programma fragile.

Domande di comprensione

Rispondi per iscritto:

• Perché il programma fragile non è stato tempo perso?
• Quali comportamenti dovremo proteggere durante il refactoring?
• Quale modifica ti farebbe più paura oggi?
• Perché non conviene riscrivere tutto subito?
• Quale responsabilità ti sembra più urgente separare?

Controllo finale

Il modulo è completato quando puoi dire sì a queste domande:

• il programma fragile funziona almeno nei casi principali;
• hai annotato cosa funziona;
• hai annotato cosa è fragile;
• hai scritto quali modifiche fanno paura;
• hai preparato un backlog architetturale;
• sai spiegare perché non bisogna riscrivere tutto subito;
• sei pronto a introdurre il concetto di architettura come responsabilità e confini.

Nel prossimo modulo daremo un nome a quello che abbiamo osservato: architettura del software come responsabilità, confini e decisioni difficili da cambiare.