Debugging: Trovarlo da solo

La maggior parte dei principianti tratta un bug come un muro. Lo colpiscono, si fermano e chiedono a qualcun altro di scavalcarlo per loro. L'abitudine che costruisce davvero l'abilità è diversa: impari a trattare un bug come una domanda con una risposta trovabile, e vai a trovarla prima di chiedere.

Leggi il messaggio di errore come se fosse una prova, non rumore

Gli stack trace vengono saltati continuamente perché sembrano spaventosi. Ma di solito ti stanno dicendo esattamente dove e perché qualcosa si è rotto. Se ottieni TypeError: 'NoneType' object is not subscriptable in Python, non è un nonsense casuale — significa che una variabile che ti aspettavi contenesse una lista o un dict è in realtà None. Il numero di riga ti dice dove. Il tuo compito è risalire all'indietro da quella riga e scoprire dove il valore avrebbe dovuto essere impostato ma non lo è stato.

Fallo prima di cercare qualsiasi cosa online: leggi l'ultima riga del traceback per primo, poi risali. L'ultima riga di solito nomina l'eccezione effettiva. Le righe sopra mostrano la catena di chiamate che ti ha portato lì.

Riproducilo di proposito

Se un bug si presenta solo a volte, non lo capisci ancora. Prima di toccare il codice, prova a farlo accadere in modo affidabile. Cambia un input alla volta. Fallisce con una lista vuota ma non con una piena? Fallisce solo alla seconda chiamata di una funzione, non alla prima? Un bug che puoi riprodurre su comando è un bug che è risolto al 80%, perché ora puoi verificare se una correzione ha effettivamente funzionato invece di indovinare.

Dividi il problema a metà, poi a metà di nuovo

La ricerca binaria non è solo per gli array ordinati — è il modo più veloce per trovare codice rotto in una funzione lunga o in una pipeline. Commenta o bypasssa la seconda metà della tua logica e verifica se la prima metà produce ancora il bug. Se sì, il problema è nella prima metà. Se no, è nella seconda. Ripeti. Questo funziona per uno script di 200 righe esattamente come funziona per una pipeline di dati multi-stage dove stai verificando gli output ad ogni fase con print() o df.head().

Questo batte il cambio casuale di righe e la riesecuzione, che è quello che la maggior parte delle persone fa sotto pressione e spreca molto più tempo di quanto ne risparmi.

Usa il debugger invece di print() quando print() smette di funzionare

Le istruzioni print() vanno bene per i casi semplici, ma una volta che stai inseguendo lo stato attraverso molteplici chiamate di funzione, un vero debugger fa risparmiare tempo reale. In Python, aggiungi import pdb; pdb.set_trace() proprio prima della riga sospetta, esegui lo script, e ottieni un prompt live dove puoi ispezionare le variabili, spostarti riga per riga con n, e entrare nelle chiamate di funzione con s. Il debugger integrato di VS Code fa la stessa cosa con i breakpoint che clicchi invece di digitare. In entrambi i casi, l'obiettivo è lo stesso: osserva lo stato effettivo del tuo programma invece di indovinare quale sia probabilmente.

Isolalo dal resto del tuo progetto

Se un bug accade all'interno di una base di codice grande, non debuggarlo dentro la base di codice grande. Copia la funzione rilevante in un file fresco con input falso e minimo che attiva lo stesso fallimento. Se il bug scompare, qualcosa nel contesto circostante — una variabile globale, un import, uno stato stantìo — è la vera causa, e hai appena imparato qualcosa di importante. Se il bug persiste in isolamento, ora hai un caso piccolo, condivisibile, testabile, e sei molto più vicino alla correzione effettiva.

Verifica i tuoi presupposti contro la realtà, non la memoria

Una parte enorme del tempo di debugging va a presupposti non messi in discussione: