Checklist di debugging per founder:l'ordine dei 5 minuti

Una checklist di debugging: quando qualcosa si rompe, controlla le cose in quest'ordine esatto: aggiorna la pagina, leggi la console, verifica di aver fatto il login, verifica che l'app sia davvero in esecuzione, verifica di aver salvato le modifiche. Questi cinque controlli richiedono cinque minuti e risolvono il 90% dei problemi. L'ordine è il metodo: la maggior parte dei fondatori fa debug tirando a indovinare, ed è per questo che resta bloccata.

Il debugging è una competenza, non magia. Ecco la checklist completa, dal controllo rapido di cinque minuti all'opzione nucleare.

Checklist di debugging, passo 1: il controllo rapido di 5 minuti (90% dei problemi)

1. Aggiorna la pagina. Cancella lo stato temporaneo e ricarica i dati. Se un semplice refresh non basta, fai un hard refresh (tieni premuto Shift mentre aggiorni), che svuota anche i file in cache che il browser potrebbe servirti dalla settimana scorsa.
2. Apri la console e cerca il rosso. La console per sviluppatori del browser è dove gli errori si annunciano. Il testo rosso è un errore, e il messaggio di solito nomina il file e la riga. Se sembra scritto in geroglifici, come leggere i messaggi di errore decodifica gli schemi ricorrenti.
3. Hai fatto il login? La maggior parte delle funzioni richiede l'autenticazione, e le sessioni scadono in silenzio. Cerca le informazioni sul tuo utente nell'intestazione; nel dubbio, esci e rientra. Una quota sorprendente di funzioni "rotte" è solo un login scaduto.
4. L'app è davvero in esecuzione? Se lavori in locale, controlla il terminale: il tuo server di sviluppo dovrebbe stampare dei log. Se è andato in crash o non è mai stato avviato, niente funzionerà, e nessuna quantità di occhiate al codice lo risolverà.
5. Hai salvato il file? Le modifiche non salvate non vengono eseguite. Cerca il pallino accanto al nome del file nel tuo editor. Sì, questo fa cadere tutti.

La maggior parte dei bug è semplice così: login non fatto, salvataggio dimenticato, server non avviato, refuso, refresh dimenticato. Parti dalle cose semplici: non è sotto la tua dignità, è statistica.

Il controllo approfondito di 15 minuti

Se il controllo rapido non l'ha trovato, scendi di un livello, sempre in ordine, sempre una cosa alla volta:

• Svuota la cache del browser. I vecchi file in cache possono entrare in conflitto con il codice nuovo. Di solito basta un hard refresh.
• Apri la scheda Network. Negli stessi strumenti per sviluppatori, la scheda Network mostra ogni richiesta fatta dalla tua app. Aggiorna la pagina e cerca le righe rosse (richieste fallite) e leggi i loro codici di stato (tabella sotto).
• Le modifiche al database sono state davvero applicate? Se di recente hai cambiato la struttura del database, verifica che la modifica sia stata eseguita: una tabella o colonna mancante rompe tutto ciò che la tocca. Controlla nella dashboard del database la tabella che ti aspetti.
• Controlla il file delle impostazioni. Le app leggono segreti e indirizzi da un file di ambiente. Valori mancanti, una chiave sbagliata o spazi in più rompono tutto, e dopo averlo modificato devi riavviare l'app perché se ne accorga.
• Sospetta la tua ultima modifica. Se funzionava un'ora fa, qualunque cosa tu abbia cambiato da allora è il principale sospettato. Annulla o commenta temporaneamente la modifica più recente e vedi se il problema sparisce.

Cosa ti dice la scheda Network

Queste quattro righe trasformano la scheda più spaventosa del browser in un infermiere di triage: ti dicono se il problema è la tua sessione, il tuo indirizzo o il tuo codice.

Il libroThe Solopreneur RevolutionLuis Gonçalves su come costruire un'attività da solopreneur con l'IA mentre sei ancora dipendente.Scopri il libro →

L'opzione nucleare

Quando nient'altro funziona, c'è la versione da sviluppatore di "spegni e riaccendi": ferma l'app, elimina le dipendenze installate, reinstallale da zero, svuota la cache del browser e riavvia. Sembra rozzo, ma risolve in modo affidabile installazioni corrotte, dipendenze obsolete e quella categoria esasperante del "sul computer del mio amico funziona, sul mio no".

Usala per ultima, non per prima: perché risolve le cose senza dirti cosa non andava, e la prossima volta sarai bloccato esattamente allo stesso modo.

Le tre regole che fanno funzionare la checklist

Cambia una cosa alla volta. Se cambi cinque cose e inizia a funzionare, non sai cosa l'ha risolto, il che significa che non sai nemmeno cosa l'aveva rotto.

Testa dopo ogni modifica. Non accumulare correzioni. Fai una modifica, controlla, vai avanti.

Documenta cosa ha funzionato. Gli stessi bug ritornano. Un file di appunti "sintomo → soluzione" diventa il tuo strumento di debug più rapido nel giro di un mese.

E quando la checklist si esaurisce: fai escalation in modo deliberato, non disperato. Passa l'errore al tuo assistente AI con i prompt di debug per l'AI, oppure scrivi una segnalazione di bug come si deve usando come chiedere aiuto tecnico. A quel punto saprai rispondere a cosa stavi facendo, cosa ti aspettavi, cosa è successo e cosa hai provato: esattamente ciò che la checklist ti ha appena fatto raccogliere.

12 settimaneLa carriera aziendale non è mai stata il pianoCandidati al Solopreneur Accelerator.Candidati ora →

Domande frequenti

Cosa devo controllare per prima cosa quando la mia app si rompe?

Aggiorna la pagina, poi leggi la console. Questi due passi richiedono meno di un minuto e da soli risolvono una grossa quota di problemi. Poi verifica di aver fatto il login, che l'app sia in esecuzione e che le modifiche siano salvate. Solo dopo questi cinque passi dovresti iniziare a leggere il codice.

Perché è importante fare debug in un ordine fisso?

Perché tirare a indovinare cambia più cose insieme, quindi non impari mai cosa non andava davvero. Un ordine fisso verifica per prime le cause più probabili e meno costose da controllare e le elimina una a una: in media è più veloce e, come bonus, ti insegna gli schemi di guasto del tuo sistema.

Le mie modifiche non compaiono: cosa c'è che non va?

In ordine di probabilità: non hai salvato il file, l'app non è in esecuzione, il browser mostra una versione in cache (hard refresh), oppure stai modificando un file diverso da quello che usa l'app. Sono tutti controlli da due minuti e insieme coprono quasi ogni caso.

Quando devo smettere di fare debug e chiedere aiuto?

Dopo il controllo rapido e quello approfondito, circa 20 minuti di lavoro sistematico. A quel punto sai dire cosa stavi facendo, cosa ti aspettavi, cosa è successo, l'errore esatto e cosa hai provato. È tutto ciò che serve a una buona richiesta di aiuto, che tu la rivolga a un'AI o a una persona.