modulo 04 / lezione 20

Isolare la causa

Una ipotesi alla volta, anche al duck

Impostare prove che confermano o smentiscono una sola spiegazione possibile. Usare il rubber duck per esplicitare assunzioni nascoste.

50 min Debugging

In parole semplici

Il debug è indagine, non caccia. L’indagine procede per ipotesi: ne formuli una, scegli una prova economica per confermarla o smentirla, registri l’esito, passi alla successiva. Un’ipotesi alla volta. Una variabile alla volta.

Strumento alleato: la rubber duck. Spiegare il problema a voce alta, anche a un peluche, forza a esplicitare assunzioni che restavano implicite.

Parole nuove

  • ipotesi: spiegazione provvisoria, da verificare.
  • falsificabilità: una buona ipotesi può essere dichiarata sbagliata da una prova.
  • prova economica: prova che richiede poco tempo e poco rischio.
  • rubber duck: pratica di “spiegare il problema a voce” per scoprire ciò che non vedi.

Cosa impari

  • Scrivere ipotesi falsificabili.
  • Scegliere prove ordinate per costo crescente.
  • Spiegare il problema in modo strutturato, anche da solo.

L’ipotesi falsificabile

“Penso che X stia succedendo perché Y. Se Y è vero, allora Z dovrebbe succedere. Verifico Z.”

Esempio sano:

“Penso che il carrello non persista perché lo store viene salvato prima dell’update. Se è vero, un log subito dopo l’update e subito prima del save mostrerà che l’update è arrivato dopo. Verifico.”

Esempio insano:

“Penso che sia un problema strano del browser.”

Il secondo non è un’ipotesi: è un alibi.

Prove ordinate per costo

Davanti a tre ipotesi, valuta sempre:

  • Costo della prova: quanto tempo, quanta complessità.
  • Informativo della prova: quanto restringe lo spazio se confermata o smentita.

Regola: parti dalla prova più economica che è anche informativa.

Esempio:

IpotesiProvaCostoInfo
Lo store non si chiamalog nel reducer1 minalto
Il fetch non tornareplay con curl2 minalto
Il browser è “strano”provare altro browser5 minbasso
C’è race con un altro listenerbreakpoint + step10 minmedio

Si parte da log nel reducer. 1 minuto, taglia metà delle ipotesi.

La rubber duck

Origina da The Pragmatic Programmer: un programmatore teneva un paperetto di gomma sulla scrivania e gli “spiegava” i bug. La metà delle volte risolveva senza ricevere risposta.

Perché funziona: spiegare costringe a esplicitare ogni passo. Le assunzioni nascoste vengono fuori. Le contraddizioni si vedono.

Formato:

  1. Cos’è il programma: cosa fa, a chi serve.
  2. Cosa dovrebbe fare adesso: input, output atteso.
  3. Cosa fa davvero: osservato.
  4. Cosa ho già escluso: ipotesi smontate.
  5. Cosa sto provando adesso: ipotesi corrente.

Spesso al punto 4 ti accorgi che non hai escluso davvero qualcosa. Lì il bug si rivela.

Variante: rubber duck con compagno reale

Quando il duck non basta, prendi un compagno. Le regole cambiano:

  • Non chiedere consigli prima di aver finito di spiegare. Spesso è inutile, il compagno si è “spento” già al punto 2.
  • Spiega per intero anche se vedi sguardi vuoti.
  • Quando arrivi al punto della rivelazione, lo capisci tu prima di lui.

Tre ipotesi concorrenti

Esercizio classico: davanti a un bug, scrivi tre ipotesi prima di provare la prima. Forza:

  • A non sposare la prima idea che passa.
  • A vedere il problema da angoli diversi.
  • A non finire in vicolo cieco senza alternativa.

Per ognuna scrivi: prova economica, esito atteso se vera, esito atteso se falsa.

Esercizio guidato

Riprendi il bug del caso minimo costruito nel modulo 1.

  1. Scrivi tre ipotesi sulla causa, ognuna falsificabile.
  2. Per ognuna scrivi la prova: comando, log, breakpoint o test.
  3. Ordina le prove per costo crescente.
  4. Esegui la prima. Registra nel taccuino: ipotesi, prova, esito.
  5. In base all’esito, scegli la seconda o ne scrivi una nuova.

Tieni un timer: 25 minuti per il ciclo. Se non hai concluso, fermati. Spiega tutto a voce alta al duck (o al peluche). Ricomincia.

Anti-pattern: il vortice

Sintomi:

  • Cambi una cosa, riprovi.
  • Sembra meglio. Cambi un’altra. Peggio.
  • Torni indietro a indovinare.
  • Dopo un’ora hai cambiato 30 righe e non ricordi più cosa.

Antidoto: fermati, ripristina (git stash o git restore), torna al taccuino. Una variabile alla volta.

Errori frequenti del principiante

  • Più ipotesi attive contemporaneamente. Non sai più cosa hai cambiato.
  • Provare a “vedere se funziona così”. Non è un’ipotesi, è una preghiera.
  • Saltare la prova più economica. “Tanto so cosa è.”
  • Saltare il taccuino. Dopo un’ora non ricordi cosa hai provato.