Debugging in laboratorio

Distinguere bug, limitazione, richiesta di funzionalità e malinteso d'uso; capire perché la stessa parola non può coprire tutto.

Capire perché alcuni errori fermano il programma prima di partire, altri durante l'esecuzione, altri ancora restano nascosti pur producendo un risultato sbagliato.

Installare e configurare browser aggiornato con DevTools, editor con linter integrato, terminale e runtime locale.

Costruire un vocabolario minimo: runtime, stack, heap, payload, fixture, regressione, throttling, source map, snapshot, postmortem.

Distinguere descrizioni emotive, sintomi tecnici, passaggi riproducibili e ipotesi non verificate, usando un template canonico (titolo, ambiente, passi, atteso, osservato, evidenze, severità).

Classificare un difetto in modo che prossimo passo, severità e responsabile siano deducibili dalla categoria.

Capire quali informazioni rendono un errore confrontabile tra computer, browser, account e ramo di codice diversi.

Ridurre un problema senza cancellare proprio la condizione che lo fa comparire; conoscere acronimi MCVE/MRE come pratica condivisa.

Separare cosa dovrebbe accadere, cosa accade davvero e quanto spesso accade, e iniziare a registrare la sessione in un taccuino strutturato (ipotesi, prove, esiti, link).

Leggere tipo, messaggio, file, riga e contesto distinguendo Error, TypeError, RangeError, SyntaxError e usando name, message, cause senza fermarsi alla prima parola spaventosa.

Seguire la catena delle chiamate distinguendo punto in cui esplode e punto in cui nasce la causa, comprendendo l'ordine LIFO dello stack.

Riconoscere lo stesso schema sotto messaggi diversi: NullPointerException (Java/Kotlin), nil (Swift), KeyError e TypeError (Python), Segmentation fault (C/C++), panic (Go, Rust).

Capire perché non tutti gli errori parlano nello stesso modo e alcuni non generano eccezioni; introdurre il concetto di assert.

Leggere 400, 401, 403, 404, 409, 422, 429, 500, 502, 503, 504 come segnali su input, permessi, conflitti, rate limit, server e gateway; usare curl o httpie oltre al pannello Network.

Scrivere log che rispondono a una domanda precisa, usare console.group/table/time/assert per dare struttura e rimuoverli o trasformarli dopo la diagnosi.

Fermare il programma nel punto giusto con breakpoint condizionati e logpoint, osservare variabili e impostare exception breakpoint senza modificare il codice.

Capire se il difetto vive nel client, nella richiesta, nel server o nei dati ricevuti; usare filtro per tipo, throttling e replay della richiesta.

Distinguere localStorage, sessionStorage, cookies, IndexedDB e cache del Service Worker; sapere quando il dato persiste e quando no.

Confrontare stato applicativo, DOM renderizzato e props/store del framework con estensioni dedicate (React DevTools, Vue DevTools, Svelte Inspector, Redux DevTools).

Impostare prove che confermano o smentiscono una sola spiegazione possibile e usare la tecnica del rubber duck per esplicitare assunzioni nascoste.

Spegnere parti del sistema con feature flag o commenti chirurgici senza introdurre nuovi bug e senza perdere il sintomo.

Tagliare lo spazio di ricerca con confronti a metà, diff e cronologia Git; usare git bisect interattivo e git bisect run con uno script di verifica.

Capire il principio del delta debugging: ridurre input o codice in modo automatico fino al minimo che fa fallire il programma.

Riconoscere input incompleti, duplicati, ordinamenti inattesi, valori limite, NaN, null, stringhe vuote, encoding misti; collegare al testing classico (boundary value, equivalence partitioning).

Separare la correzione necessaria da refactor e pulizie che rischiano di confondere la verifica, anche quando il codice toccato fa prudere le mani.

Trasformare il bug trovato in una verifica automatica o E2E (Playwright/Cypress, snapshot, asserzioni mirate) che fallisce prima del fix e passa dopo.

Controllare il caso principale, un caso vicino, un caso limite e un caso che non deve cambiare prima di dichiarare chiuso il bug.

Decidere consapevolmente tra correggere in avanti, fare git revert, usare git reset locale o aprire un branch hotfix, valutando rischio e urgenza.

Rendere comprensibile nel tempo cosa è stato corretto, perché e come è stato verificato, usando Conventional Commits e la regola 50/72 per oggetto e corpo.

Formulare una richiesta che include contesto, prove già fatte e punto esatto in cui si è bloccati, prendendo spunto dalla tradizione How To Ask Questions The Smart Way.

Classificare un ticket per impatto, urgenza, proprietario e scadenza così che la coda non diventi caos.

Dividere ruoli tra chi guida, chi osserva, chi prende note e chi verifica, alternandoli con timer.

Valutare una correzione guardando diff, test, casi limite, retro-compatibilità, side effect e rischio di regressione, usando una checklist canonica di review.

Convertire un errore risolto in una regola, un test, una checklist o una decisione di progetto, usando il formato blameless postmortem.

Capire perché codice scritto in una sequenza può produrre effetti in un ordine diverso durante l'esecuzione, distinguendo task, microtask (Promise, queueMicrotask) e rendering frame.

Riconoscere promise non attese, catch mancanti, stati pendenti, unhandled rejection e fallimenti che non arrivano in console.

Riconoscere e prevenire race condition (doppio submit, stale closure, setState dopo unmount) e usare AbortController per cancellare fetch e listener.

Individuare listener duplicati, eventi non rimossi, propagazione inattesa, stato UI non sincronizzato e bug specifici del framework (stale closure React, reactivity Vue, store leak Svelte).

Diagnosticare bug provocati da cache di Service Worker o CDN, collegare codice sorgente, bundle e componente renderizzato attraverso le source map.

Controllare se richiesta, risposta e modello dati concordano su nomi, tipi, valori mancanti, formati e versione dell'API.

Distinguere errori di identità, permessi, cookie (SameSite, Secure, HttpOnly), token JWT (firma, scadenza, audience), CORS preflight OPTIONS e scadenza sessione.

Riconoscere bug causati da ordinamenti, join, vincoli mancanti, migrazioni incomplete e record incoerenti.

Riconoscere bug che dipendono da fuso orario, salvataggio in UTC vs locale, encoding misto (UTF-8 vs Latin-1), formattazione numerica e date.

Capire come retry mal progettati creano duplicati, perché serve idempotency-key, quando un messaggio finisce in dead letter queue e come confrontarsi con servizi esterni instabili.

Trovare differenze tra locale, preview e produzione dovute a env, versioni, cache, build, lock file o servizi collegati.

Misurare prima di ottimizzare, distinguendo CPU, layout, rendering, caricamento asset e tempi di risposta; leggere LCP, INP, CLS e TTFB come segnali utente, usando User Timing API (performance.mark e performance.measure).

Riconoscere crescita anomala della memoria, listener rimasti attivi, timer pendenti, sottoscrizioni store e riferimenti trattenuti che impediscono la garbage collection.

Profilare un servizio backend (Node, Python, Java) e leggere flamegraph generati con perf, py-spy o async-profiler per individuare hot path.

Costruire segnali utili in produzione (log JSON con livello e correlation id, metriche RED/USE, trace distribuiti) senza esporre dati sensibili e senza affogare l'indagine nel rumore; introdurre SLI, SLO ed error budget.

Gestire un difetto già rilasciato: contenere l'impatto, aggiornare gli utenti via status page, coordinare la war room, scegliere rollback o fix-forward in coordinamento con il Modulo 5, poi documentare la causa.

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

Applicare osservazione, isolamento e delta debugging per arrivare a una causa verificata, mantenendo il taccuino.

Applicare fix minimo, scrivere test di regressione, eseguire matrice di verifica e preparare commit e branch.

Presentare il caso a un compagno o docente in massimo dieci minuti, ricevere review, scrivere retrospettiva blameless e lezioni apprese.