4 risposte

★ Miglior risposta

Una cosa che non vedi mai menzionata è usare il Network tab in parallelo. Spesso pensi che il tuo JavaScript sia bugato quando invece il problema è che una API call è fallita silenziosamente o ha restituito dati strani. Controlla sempre le risposte del backend prima di scavare nel tuo codice front-end - ti risparmia ore.

Per il resto, il vero trucco è imparare a leggere lo stack trace. Quando un errore salta fuori, non guardare solo dove dice "errore qui", ma traccia il percorso di chiamate che lo ha causato. Spesso la vera fonte del bug è due o tre livelli più su nella catena. E se usi TypeScript o un linter decente, già catchi buona parte dei problemi prima ancora di fare debugging vero.

Quanti console.log() stai mettendo nel codice prima di accorgerti che Chrome DevTools ha già tutto quello che ti serve?

Il vero cambio di prospettiva è smettere di pensare al debugging come a una caccia al tesoro disperata. Chrome DevTools ha le Sources, che ti permettono di mettere breakpoint veri e propri - non solo "stampa questo valore e spera" - e di steppare riga per riga attraverso il codice. La cosa che la gente non usa abbastanza è il watch di variabili specifiche, così guardi in tempo reale cosa cambia mentre il codice gira. Poi c'è il console drawer che rimane sempre a portata di mano, perfetto per fare quick check senza interrompere l'esecuzione.

Altra cosa che mi ha salvato parecchie volte: usare il Network tab non solo per vedere se le richieste partono, ma per controllare esattamente cosa ricevi dal server. Più volte ho passato ore a debuggare logica che era in realtà un problema nei dati che arrivavano. Se l'app è complessa e ha uno stato interno, il Vue DevTools o React DevTools (dipende da cosa usi) sono killer - vedi lo stato mutare in tempo reale e torni indietro negli stati precedenti. Non è magia, è solo che la gente spesso non sa che esistono.

Ah, e un'ultima cosa banale ma vera: metti breakpoint condizionali. Non sempre vuoi fermarti su una riga, vuoi fermarti solo quando una certa variabile ha un certo valore. Almeno risparmi tempo a cliccare "continue" mille volte.

Non sprecare tempo a piazzare breakpoint a caso nelle funzioni; invece, usa le Chrome DevTools Conditions per far fermare l'esecuzione solo quando una variabile raggiunge un valore specifico - cambia completamente il modo in cui tracci i bug nelle app complesse. E quando sei davanti a un errore che sembra casuale, il Network tab spesso rivela quello che non vedi nel codice, tipo race condition o risposte API malformate.

Quando cominci a debuggare, quanti breakpoint metti prima di realizzare che probabilmente il problema è altrove?

Quello che manca spesso è un approccio sistematico. Chrome DevTools è potentissimo ma molti usano solo console.log e breakpoints classici. Prova i conditional breakpoints: clicca destro sulla linea di codice, scegli "Add conditional breakpoint" e scrivi la condizione che ti interessa. Tipo, un breakpoint che scatta solo quando `user.id === undefined` invece di fermarti ogni volta. Poi usa il Logpoints (simile, ma stampa un messaggio senza fermare l'esecuzione) quando hai bisogno di tracciare valori senza rompere il flusso.

Un trucco che pochi conoscono: nella scheda Network di DevTools, puoi filtrare e guardare esattamente cosa sta andando male con le tue richieste. Se l'app si comporta strano, spesso il problema è che una request non è quello che credi oppure la risposta è malformata. Usa anche la scheda Performance se sospetti lag: registra quello che succede e vedi dove il codice rallenta davvero. Infine, impara a usare gli Watch expressions: nella sezione Scope, aggiungi le variabili che ti interessano e vedile aggiornare in tempo reale mentre avanzi nel codice. Risparmi un sacco di stampe inutili.

ricci1987 asker Grazie per i consigli! I conditional breakpoint e i logpoints non li usavo, sono esattamente quello che cercavo. Proverò subito la scheda Network per le richieste.

La tua risposta

Accediper rispondere.