modulo 01 / lezione 09

Riprodurre il bug

Atteso, osservato, frequenza, taccuino di laboratorio

Separare cosa dovrebbe accadere, cosa accade davvero, quanto spesso accade. Iniziare a registrare la sessione in un taccuino strutturato.

50 min Debugging

In parole semplici

Tre domande chiudono la fase di riproduzione:

  1. Atteso: cosa dovrebbe succedere?
  2. Osservato: cosa succede davvero?
  3. Frequenza: quanto spesso, in quali condizioni?

E una pratica le tiene insieme: il taccuino di laboratorio, lo spazio dove registri ipotesi, prove ed esiti. Senza taccuino, ogni sessione di debug è una memoria che evapora.

Parole nuove

  • deterministico: a parità di input, stesso output. Ogni volta.
  • intermittente: ogni tanto fallisce, ogni tanto no.
  • dipendente da dati: fallisce solo con certi input.
  • taccuino di laboratorio: registro cronologico della sessione di debug.

Cosa impari

  • Scrivere atteso e osservato senza confonderli.
  • Classificare il bug per frequenza in tre categorie operative.
  • Tenere un taccuino utile: minimo, ordinato, riutilizzabile.

Atteso vs osservato

L’errore più frequente è scrivere ipotesi in “osservato”.

Sbagliato:

OSSERVATO: il database non salva il record.

Questa è un’ipotesi, non un’osservazione. Tu non hai visto il database. Hai visto che dopo il refresh il record manca. Sono due cose diverse.

Corretto:

OSSERVATO: dopo aver cliccato "Salva", la pagina mostra "Salvato".
Ricaricando la pagina, il record creato non appare nella lista.

Osservato = ciò che vedi sullo schermo o nei log. Niente di più.

Frequenza: tre categorie

1. Deterministico

A parità di input, esito uguale. È il sogno del debugger.

“Ogni volta che provo a registrare un utente con email contenente +, vedo errore 400.”

2. Intermittente

A parità di apparente input, esito diverso. Servono indagini sulle condizioni nascoste (rete, timing, cache, race condition).

“A volte sì, a volte no, anche con gli stessi dati.”

3. Dipendente da dati

Determinato, ma solo per certi input. Sembra intermittente perché non sai ancora quale dato lo scatena.

“Si verifica solo con utenti registrati prima del 2020.”

La differenza tra intermittente vero e dipendente da dati spesso si risolve raccogliendo molti casi e cercando il pattern.

Il taccuino di laboratorio

Un file taccuino.md per ogni bug. Esempio di sessione:

# Bug #142 — Carrello vuoto dopo refresh

## 2026-05-16, 09:30 — Apertura
Etichetta: regressione
Severità: alta, Priorità: sprint
Caso minimo: stackblitz.com/edit/xyz

## 09:35 — Ipotesi 1
Lo store non persiste in localStorage.
PROVA: aprire DevTools → Application → Local Storage, vedere se 'cart' esiste dopo "Salva".
ESITO: la chiave 'cart' esiste, ma è vuota.
CONSEGUENZA: lo store salva, ma il payload è vuoto al momento del salvataggio.

## 09:48 — Ipotesi 2
Il `commit` dello store viene chiamato prima dell'aggiornamento del carrello.
PROVA: log strutturato in `addToCart` e nel reducer di salvataggio.
ESITO: la chiamata a salvataggio precede il dispatch finale.
CONSEGUENZA: race condition tra dispatch e save. Indagine continua su timing.

## 10:15 — Fix candidato
Spostare la chiamata `save()` dentro il selector dopo lo state update.
PROVA: applicare, ricaricare 10 volte.
ESITO: il carrello persiste in tutte le prove.

Formato libero, ma sempre con: ora, ipotesi, prova, esito.

Perché il taccuino fa la differenza

  • Non perdi il filo quando il debug dura ore o giorni.
  • Riprendi dove avevi lasciato senza ricostruire tutto.
  • Condividi la sessione con chi ti subentra (modulo 6).
  • Impari rileggendo: i pattern di indagine ricorrenti diventano abitudini.

Esercizio guidato

  1. Prendi il caso minimo dell’esercizio precedente.
  2. Apri taccuino.md.
  3. Scrivi atteso/osservato per il bug.
  4. Classificalo per frequenza: deterministico, intermittente o dipendente da dati. Motiva la scelta.
  5. Apri tre ipotesi possibili, in ordine di costo crescente. Per ciascuna scrivi: prova e esito atteso.

Non eseguire ancora le prove: la prossima sessione (modulo 4) le farà.

Errori frequenti del principiante

  • Scrivere osservato e atteso uguali. Significa che non hai capito cosa è davvero successo.
  • Saltare la frequenza. “A volte” è la risposta più costosa del debug. Conta quante volte su 10.
  • Tenere il taccuino “a mente”. Dopo 40 minuti, la memoria di debug è già corrotta da nuove ipotesi.
  • Trasformare il taccuino in romanzo. Frasi brevi, fatti, esiti. Non motivazioni emotive.