modulo 10 / lezione 51

Capstone: bug reale end-to-end

Capstone: kickoff e riproduzione

Aprire il caso del capstone, leggere la segnalazione iniziale, costruire caso minimo riproducibile, pianificare le sessioni.

60 min Debugging

In parole semplici

Il capstone è la prova del corso: un bug reale e composto, distribuito tra client, server e dati. Lo affronterai in quattro sessioni applicando tutto il metodo dei moduli 0-9. Questa lezione apre il caso: ricevi la segnalazione, riproduci, pianifichi.

Cosa porti

Da qui in poi, niente lezione frontale. Il capstone è esercizio integrato: applichi i moduli precedenti su un caso realistico.

Strumenti che dovresti aver pronti dal modulo 0:

  • Browser moderno con DevTools.
  • Editor con linter.
  • Terminale + Node + Git.
  • Repo capstone fornito dal corso, scaricabile da /capstone-debugging/ (cartelle client/ e server/).
  • Taccuino di laboratorio aperto.

Cosa impari (rivedere applicare)

  • Modulo 1: bug report, ambiente, caso minimo, atteso/osservato/frequenza, taccuino.
  • Pianificazione di indagine: budget di tempo, ipotesi, milestone.
  • Lavorare su codebase reale (non più snippet).

La segnalazione (esempio simulato)

SEGNALAZIONE INIZIALE #C-001
Da: Customer Success
Data: oggi, 09:15

"Diversi utenti riportano problemi con il checkout.
Vedono 'Ordine confermato' ma poi nella sezione 'I miei ordini'
non c'è nulla, oppure ci sono ordini duplicati.

A volte funziona, a volte no. Sembra peggiorare nelle ore di punta."

Severità: alta (potenziale perdita revenue)
Priorità: P1 (sprint)
Owner: tu

Niente passi, niente ambiente preciso, niente caso minimo. È un lamento (modulo 1.1). Il tuo lavoro inizia trasformandolo in bug report utile.

Sessione di kickoff: scaletta 60 minuti

0–15 min: leggere e contestualizzare

  • Apri il repo capstone. Leggi il README.
  • Familiarizza con la struttura: client, server, DB, code di messaggi.
  • Identifica i punti del flusso “checkout” coinvolti.

15–30 min: bug report

Riscrivi la segnalazione usando il template (modulo 1.1):

TITOLO: Ordini scomparsi o duplicati dopo "Ordine confermato"

AMBIENTE: (riempi con la tua postazione capstone)

PASSI (ipotesi iniziale):
1. Login utente
2. Aggiunta prodotti al carrello
3. Click "Checkout"
4. Click "Conferma ordine"
5. Vai a "I miei ordini"

ATTESO: nuovo ordine presente esattamente una volta.
OSSERVATO: a volte mancante, a volte duplicato.

FREQUENZA: intermittente
EVIDENZE: -
SEVERITÀ: alta. PRIORITÀ: P1.

Sì, è ancora pieno di buchi. Lo riempirai nei prossimi 30 minuti.

30–45 min: riprodurre

Esegui il flusso a mano nel repo capstone, una decina di volte. Cosa succede?

Tre esiti possibili:

  • Bug subito riproducibile: ottimo, hai un caso deterministico.
  • Bug intermittente: registra quante volte su 10 si manifesta (es. 3/10).
  • Bug non riproducibile: probabilmente serve un input/condizione specifica (utente, prodotto, carico).

In capstone realistici, è intermittente. Categorizza per frequenza (modulo 1.5).

45–55 min: prime osservazioni

Apri DevTools. Per ogni tentativo:

  • Network: cosa risponde /checkout? /ordini?
  • Console: errori?
  • Application: cookie, storage?

Annota nel taccuino:

Tentativo 1: 200 su /checkout, 200 su /ordini, ordine presente. OK.
Tentativo 2: 200 su /checkout, /ordini ritorna 0 ordini. Bug.
Tentativo 3: 200 su /checkout (x2!), /ordini ritorna 2 ordini. Bug (duplicato).
...

55–60 min: pianificazione

Decidi: tre o quattro ipotesi da indagare nella prossima sessione.

Esempio:

  1. Race condition tra “Conferma” e refresh ordini.
  2. Doppio submit del pulsante “Conferma” (modulo 7.3).
  3. Idempotenza mancante lato server (modulo 8.5).
  4. Caching aggressivo della lista ordini.

Per ognuna: prova economica da fare in sessione 2.

Caso minimo (anticipato)

Se possibile, costruisci un caso minimo:

  • Singolo utente, singolo prodotto, doppio click “Conferma” rapido.

Annota:

  • Quanti millisecondi tra i click producono duplicati?
  • Quale richiesta vediamo doppia in Network?

Caso minimo ridotto al massimo: doppio click su submit di 1 prodotto, da 200ms in giù = duplicato. Da 500ms in su = ok.

Esito atteso della sessione di kickoff

Alla fine dei 60 minuti, hai:

  • ✅ Bug report compilato (con i buchi che ti servono per la prossima sessione).
  • ✅ Caso minimo riproducibile (o procedura per riprodurre).
  • ✅ Categoria di frequenza dichiarata (intermittente, dipendente da timing).
  • ✅ Tre o quattro ipotesi numerate, con prova economica.
  • ✅ Taccuino con timeline della sessione.

Errori frequenti del capstone

  • Saltare il bug report. Si parte a indagare senza scrivere → si perde il filo.
  • Pretendere di “vedere” il bug al primo tentativo. Intermittente significa: prova 10 volte.
  • Riprodurre senza DevTools aperto. Si perde l’occasione.
  • Pianificare 12 ipotesi. Ne basta una alla volta. Le altre vengono dopo.

Buon capstone. Nella prossima lezione: indagine vera e propria.