Esercizio: correggere tre rischi semplici

Questa lezione appartiene al Modulo 18 — Sicurezza di base.

I tre rischi da correggere

Questo esercizio ha un obiettivo preciso: trovare e correggere tre problemi specifici nel progetto. Non sono astratti — sono i rischi più comuni nei progetti scolastici.

Rischio 1: input non validato che arriva al dominio

Il problema: il valore di un campo form viene passato direttamente al caso d’uso senza nessun controllo. Se il campo è vuoto, il dominio riceve una stringa vuota o undefined e produce dati corrotti.

Dove cercarlo: nei form della Presentation — ogni punto in cui si legge input.value e lo si mette in un comando.

// ❌ Rischio: nessun controllo sul nome
const comando = {
  id: crypto.randomUUID(),
  nome: document.getElementById("nome").value,  // può essere ""
  categoria: document.getElementById("categoria").value
};
registraStrumento(comando);

// ✅ Corretto: validazione prima di creare il comando
const nome = document.getElementById("nome").value.trim();
if (nome.length < 2) {
  mostraErrore("Il nome deve avere almeno 2 caratteri.");
  return;
}
const comando = { id: crypto.randomUUID(), nome, categoria };
registraStrumento(comando);

Come verificarlo: inserisci un nome vuoto nel form e premi il pulsante. Il sistema mostra un errore comprensibile o produce dati corrotti?

---

Rischio 2: messaggio tecnico mostrato all’utente

Il problema: un errore JavaScript grezzo (Cannot read properties of undefined, QuotaExceededError, codice errore interno) viene mostrato direttamente all’utente invece di un messaggio comprensibile.

Dove cercarlo: nei blocchi catch della Presentation — ogni punto in cui si cattura un errore e si mostra qualcosa.

// ❌ Rischio: mostra il messaggio tecnico grezzo
try {
  await registraPrestito(comando);
} catch (errore) {
  alert(errore.message); // mostra "STRUMENTO_NON_TROVATO" o stack trace
}

// ✅ Corretto: traduce il codice in messaggio comprensibile
try {
  await registraPrestito(comando);
} catch (errore) {
  const messaggi = {
    STRUMENTO_NON_TROVATO: "Strumento non trovato. Controlla l'ID.",
    STRUMENTO_NON_DISPONIBILE: "Questo strumento non può essere prestato.",
    ARCHIVIO_NON_DISPONIBILE: "Impossibile salvare. Riprova tra poco."
  };
  mostraMessaggio(messaggi[errore.message] ?? "Operazione non riuscita.");
  console.error("Dettaglio tecnico:", errore); // conserva il dettaglio nel log
}

Come verificarlo: prova a prestare uno strumento inesistente o guasto. Cosa vede l’utente?

---

Rischio 3: regola del dominio scritta nella UI

Il problema: un controllo che riguarda le regole del laboratorio (es. “uno strumento guasto non si presta”) è scritto direttamente nell’event listener della UI invece che nel dominio.

Dove cercarlo: negli event listener dei form — condizioni if che controllano lo stato di strumenti o prestiti.

// ❌ Rischio: regola del dominio nell'event listener
document.getElementById("btn-presta").addEventListener("click", () => {
  const strumento = trovaStrumento(strumentoId);
  if (strumento.stato === "guasto") {  // ← questa regola appartiene al dominio
    mostraErrore("Strumento guasto.");
    return;
  }
  registraPrestito(comando);
});

// ✅ Corretto: la regola sta nel dominio, la UI gestisce solo l'errore
// domain/strumento.js
function puoEsserePrestato(strumento) {
  if (strumento.stato !== "disponibile") throw new Error("STRUMENTO_NON_DISPONIBILE");
}

// presentation/ — event listener semplice
document.getElementById("btn-presta").addEventListener("click", async () => {
  try {
    await registraPrestito(comando); // il caso d'uso chiama puoEsserePrestato
  } catch (errore) {
    mostraMessaggio(messaggi[errore.message] ?? "Operazione non riuscita.");
  }
});

Come verificarlo: prova a spostare il file domain/strumento.js in un progetto diverso. Le regole di prestabilità funzionano ancora senza la UI?

---

L’esercizio in tre passi

1. Trova ogni rischio nel tuo progetto. Usa grep o cerca manualmente:

   • Rischio 1: cerca input.value senza .trim() o controllo lunghezza
   • Rischio 2: cerca catch con alert(errore.message) o simile
   • Rischio 3: cerca strumento.stato === dentro event listener

2. Correggi un rischio alla volta. Verifica che il comportamento visibile non sia cambiato prima di passare al successivo.

3. Documenta con una nota nel README o nella scheda: quale rischio hai trovato, dove stava, come lo hai corretto.

Attività in classe

## Tre rischi trovati nel mio Registro

Rischio 1 (input non validato):
  - Trovato in: [file:riga]
  - Correzione applicata:
  - Verifica:

Rischio 2 (messaggio tecnico all'utente):
  - Trovato in: [file:riga]
  - Correzione applicata:
  - Verifica:

Rischio 3 (regola del dominio nella UI):
  - Trovato in: [file:riga]
  - Correzione applicata:
  - Verifica:

Rischio non trovato (se applicabile):
  - Tipo: [1/2/3]
  - Motivo per cui non è presente (era già corretto? non applicabile?):

Spiegazione guidata per studiare

I tre rischi di questa lezione non sono teorici — compaiono quasi sempre nei progetti costruiti in fretta o senza prestare attenzione ai confini tra livelli.

Il punto centrale è: ogni rischio ha un livello di appartenenza. L’input non validato è un problema del bordo tra Presentation e Application. Il messaggio tecnico esposto è un problema del bordo tra Application e Presentation. La regola nella UI è un problema del bordo tra Presentation e Domain.

Riconoscere il livello sbagliato è il primo passo per correggere il rischio nel posto giusto — non nel posto più comodo.

Passo per passo nel progetto

1. Apri tutti i file della cartella presentation/ (o src/ui/).
2. Cerca input.value senza .trim() — aggiungi validazione dove manca.
3. Cerca blocchi catch che mostrano errore.message direttamente — aggiungi dizionario messaggi.
4. Cerca condizioni if (strumento.stato === ...) dentro event listener — sposta nel dominio.
5. Per ogni correzione: verifica che il comportamento del Registro sia identico prima e dopo.

Esempio da leggere lentamente

// Tre rischi in 10 righe — tutto in un unico event listener
document.getElementById("btn-presta").addEventListener("click", () => {
  const nome = document.getElementById("nome").value; // ← Rischio 1: no trim, no check
  const strumento = trovaStrumento(strumentoId);

  if (strumento.stato === "guasto") { // ← Rischio 3: regola del dominio nella UI
    alert("Guasto"); // ← Rischio 2: messaggio tecnico / troppo vago
    return;
  }
  registraPrestito({ nome, strumentoId });
});

Tre righe, tre rischi. Tutti correggibili in 15 minuti.

Prova di comprensione

• Hai trovato tutti e tre i rischi nel tuo progetto? Se uno non c’era, era già corretto o non applicabile?
• Dopo le correzioni, il comportamento visibile del Registro è cambiato? (Non dovrebbe.)
• Riesci a spiegare a un compagno perché ogni rischio appartiene al livello sbagliato?

Errori da evitare

• correggere il rischio nel posto sbagliato (es. spostare la validazione nel dominio invece che nell’Application);
• rimuovere il console.error insieme al messaggio grezzo — il log tecnico serve;
• modificare più di un file alla volta senza verificare tra un passo e l’altro;
• considerare completata la lezione senza aver verificato il comportamento dopo ogni correzione.

Prodotto da consegnare

Può essere:

• tre modifiche al codice, una per rischio, con commento che spiega il perché;
• la scheda compilata con i tre rischi trovati e le correzioni applicate;
• un test manuale documentato che verifica il comportamento dopo ogni correzione.

Checklist di chiusura

• Rischio 1 trovato e corretto: input validato prima di creare il comando
• Rischio 2 trovato e corretto: messaggio utente comprensibile al posto del codice tecnico
• Rischio 3 trovato e corretto: regola del dominio spostata fuori dall’event listener
• Il comportamento del Registro è identico prima e dopo le correzioni
• Il log tecnico (console.error) è ancora presente dove serve

Domande per la revisione

• Quale dei tre rischi era più nascosto nel tuo progetto?
• Hai trovato rischi aggiuntivi oltre ai tre richiesti?
• Dopo le correzioni, il codice è più facile o più difficile da leggere? Perché?

Risultato atteso

Alla fine lo studente deve saper dire:

Ho trovato e corretto questi tre rischi nel Registro:
1. Input non validato in [file]: ho aggiunto [correzione].
2. Messaggio tecnico in [file]: ho aggiunto [dizionario messaggi].
3. Regola del dominio nella UI in [file]: ho spostato [funzione] nel dominio.
Ho verificato che il comportamento è rimasto identico.

Se questa spiegazione non è possibile, la lezione non è ancora davvero conclusa.