Introdurre un bug realistico causato dal disordine

Un buon laboratorio non mostra solo il codice che funziona. Mostra anche come si rompe.

In questa lezione introdurremo un bug realistico, cioè un errore credibile in un progetto piccolo:

lo stesso stato viene scritto in due modi diversi

Esempio:

in_prestito
in prestito

Per una persona sono quasi la stessa cosa. Per il programma sono due valori diversi.

Obiettivo della lezione

Alla fine devi saper:

• riprodurre un bug legato agli stati;
• distinguere causa tecnica e causa architetturale;
• capire perché le stringhe duplicate sono pericolose;
• vedere come localStorage può conservare dati sbagliati;
• correggere il bug immediato senza fingere che il problema sia risolto per sempre;
• scrivere una piccola scheda di analisi.

Questa lezione non serve a “fare casino”. Serve a imparare a leggere un errore con metodo.

Perché questo bug è realistico

Nel nostro codice gli stati sono stringhe sparse.

Nell’event listener del prestito potresti avere:

if (strumento.stato === "in_prestito") {
  messaggioElement.textContent = "Lo strumento è già in prestito";
  return;
}

Nell’HTML ci sono altre stringhe:

<option value="in_prestito">In prestito</option>

Nel cambio stato potresti scrivere per errore:

<option value="in prestito">In prestito</option>

Visivamente sembra uguale. Tecnicamente non lo è.

Questo bug è realistico perché nasce da una situazione comune:

• valori ripetuti in più file;
• nessun punto unico in cui definire gli stati;
• nessun test che protegge la regola;
• UI che può modificare direttamente il dato.

Introdurre il bug

Nel select del nuovo stato modifica temporaneamente questa opzione:

<option value="in_prestito">In prestito</option>

in:

<option value="in prestito">In prestito</option>

Ora usa il cambio stato per segnare uno strumento come In prestito.

La UI mostrerà:

in prestito

Ma la regola del prestito controlla:

if (strumento.stato === "in_prestito") {
  messaggioElement.textContent = "Lo strumento è già in prestito";
  return;
}

Risultato possibile: il programma permette un nuovo prestito per uno strumento che nella UI sembra già in prestito.

Riprodurre il bug

Segui questa sequenza:

1. scegli str-001;
2. cambia stato in In prestito usando il select rotto;
3. osserva il valore mostrato nella lista;
4. prova a registrare un prestito per str-001;
5. controlla se il sistema blocca o permette l’operazione;
6. apri DevTools e guarda il valore salvato, se usi localStorage.

Se il controllo non blocca, hai un bug di dominio causato da una stringa incoerente.

Il bug non è solo “ho scritto male una parola”. Il bug è:

il sistema non ha un modo affidabile per rappresentare gli stati

Causa tecnica

La causa tecnica è locale e precisa:

"in prestito" non è uguale a "in_prestito"

Puoi verificarlo anche in console:

"in prestito" === "in_prestito";

Il risultato è:

false

Il programma confronta caratteri, non intenzioni.

Causa architetturale

La causa architetturale è più interessante:

• gli stati sono stringhe libere;
• le stringhe sono duplicate in HTML e JavaScript;
• la UI può impostare direttamente lo stato;
• la regola è dentro l’event listener;
• non esiste un modello di dominio che controlla i passaggi ammessi;
• non esistono test sulla regola.

La causa tecnica spiega l’errore immediato.

La causa architetturale spiega perché l’errore era facile da introdurre.

Correzione minima, non definitiva

Per ora correggi il valore HTML:

<option value="in_prestito">In prestito</option>

Questa correzione elimina il bug immediato, ma non elimina la fragilità.

Perché?

Perché domani qualcuno potrebbe scrivere una nuova stringa sbagliata in un altro punto.

La soluzione più robusta arriverà dopo:

• definiremo gli stati in un punto solo;
• sposteremo le regole nel dominio;
• impediremo passaggi di stato non validi;
• scriveremo test.

Il secondo problema: dati vecchi in localStorage

Se hai salvato lo stato sbagliato in localStorage, correggere l’HTML potrebbe non bastare.

Il browser potrebbe continuare a caricare:

{
  "stato": "in prestito"
}

In questo caso puoi pulire i dati di test:

localStorage.clear();

Oppure puoi correggere manualmente il valore salvato negli strumenti di sviluppo.

Questa è un’altra lezione importante: quando introduci persistenza, i bug possono sopravvivere al refresh.

Il codice cambia, ma il dato sbagliato resta.

Scheda di analisi del bug

Compila una scheda come questa:

Bug osservato:
  Uno strumento marcato come "in prestito" può essere prestato di nuovo.

Passi per riprodurlo:
  1. Cambiare stato con valore "in prestito"
  2. Registrare un prestito
  3. Osservare che la regola non blocca

Causa tecnica:
  Stringhe diverse: "in prestito" e "in_prestito"

Causa architetturale:
  Stati duplicati e regole sparse nella UI

Correzione immediata:
  Allineare il valore dell'opzione HTML

Correzione futura:
  Definire StatoStrumento nel dominio e testare la regola

Questa scheda vale più di una correzione veloce, perché rende visibile il ragionamento.

Cosa non fare

Non risolvere il problema così:

if (strumento.stato === "in_prestito" || strumento.stato === "in prestito") {
  messaggioElement.textContent = "Lo strumento è già in prestito";
  return;
}

Questa patch può tamponare il bug, ma aumenta il disordine:

• accetta due rappresentazioni dello stesso concetto;
• nasconde il problema invece di eliminarlo;
• rende più difficile capire quale valore sia corretto;
• invita a gestire altri casi speciali in futuro.

Per ora la correzione minima è allineare il valore. La correzione progettuale arriverà quando introdurremo il dominio.

Attività guidata

1. Introduci il valore sbagliato in prestito.
2. Riproduci il bug.
3. Controlla il valore nella UI.
4. Controlla il valore in localStorage, se presente.
5. Scrivi la scheda di analisi.
6. Correggi il valore in HTML.
7. Svuota localStorage, se necessario.
8. Ripeti la prova.

Non saltare la scheda: è lì che impari a distinguere l’errore dalla causa.

Micro-sfida

Trova un altro punto in cui una stringa duplicata potrebbe creare un bug.

Esempi:

• guasto scritto come rotto;
• disponibile scritto come available;
• categoria notebook scritta come Notebook;
• ID strumento scritto con spazi;
• categoria elettronica scritta come elettronico.

Risultato atteso: una nuova scheda di analisi con causa tecnica e causa architetturale.

Prodotto da ottenere

Alla fine della lezione devi avere:

• bug riprodotto almeno una volta;
• bug corretto nella forma minima;
• eventuale localStorage ripulito;
• scheda di analisi compilata;
• almeno un altro rischio simile individuato;
• nota sulla soluzione futura: StatoStrumento nel dominio.

Domande di comprensione

Rispondi per iscritto:

• Perché in_prestito e in prestito sono diversi per JavaScript?
• Qual è la causa tecnica del bug?
• Qual è la causa architetturale del bug?
• Perché localStorage può far ricomparire un errore già corretto nel codice?
• Perché accettare due stringhe diverse nello stesso controllo non è una buona soluzione?

Controllo finale

La lezione è completata quando puoi dire sì a queste domande:

• ho riprodotto un bug realistico;
• so spiegare la differenza tra causa tecnica e causa architetturale;
• ho capito perché le stringhe duplicate sono pericolose;
• ho visto che localStorage può conservare dati sbagliati;
• ho scritto una scheda di analisi del bug;
• so quale soluzione futura renderà il problema meno probabile.

Nel prossimo passo leggeremo il codice fragile come se facessimo una piccola revisione tecnica.