Come gestisci errori davvero bizzarri che ti lasciano perplesso per più di 10 ore? [chiuso]

Per quei problemi davvero orribili la mia strategia di solito va come segue.

• Esperimento e google. Continua a provare a risolvere il problema. Il più delle volte questo risolve il problema in un'ora o meno.

• Quindi non ha funzionato. Fare una pausa. Prendi un caffè, parla di qualcosa che non è correlato a un collega. Elimina il problema dalla tua mente. Quando guardi il problema 5 o 10 minuti dopo lo stai guardando da una prospettiva leggermente diversa. Il più delle volte funziona.

• In questo caso non è così. Quindi trascorri altri 10-30 minuti a guardarlo. Quindi chiama un collega. Ma prima di farlo, prendi appunti; vuoi dimostrare il problema, riprodurlo, elencare le cose che hai provato e, cosa più importante, provare che le hai provate. Quindi fai prima una prova a secco. Imposta alcuni segni di libro nel codice, chiudi tutti i documenti aperti superflui, ecc. In questo modo puoi risolvere il problema tu stesso, o quando dimostri il problema non perderai il loro tempo.

• Chiedi al tuo collega di farti dimostrare tutte le tue supposizioni. questo setter sta davvero invocando? Questo metodo restituisce davvero ciò che affermi che sia? Pensi che l'oggetto non sia nullo: mostra loro che non è nullo.

• La maggior parte delle volte, sia dimostrando il problema, ti renderai conto che non hai provato tutte le possibilità o il tuo collega vedrà il tuo errore.

• Se non funziona, è tempo di fare sul serio. Documenta esattamente cosa stai cercando di fare, cosa hai provato e perché non ha funzionato. Invia questo a tutti i tuoi colleghi. Pubblicalo su SO. A questo punto il documento dovrebbe essere una perfetta domanda SO.

• Mentre aspetti le risposte, google google google. Prova ogni permutazione della domanda che hai. Apri un mucchio di schede. Probabilmente non otterrai una risposta a questo punto, ma stai cercando idee, possibilità, diversi modi di affrontare il problema.

• Fai qualcos'altro, se hai passato 5 ore su un problema è tempo di lasciarlo per un altro giorno. Forse avrai una risposta utile. Forse quando attacchi il problema il giorno dopo sarà ovvio.

• Se non funziona, è tempo di cercare una soluzione diversa. Forse puoi usare un metodo diverso, una tecnologia diversa. Forse dovresti considerare di abbandonare la funzione per ora. Stai fatturando il cliente a ore? Stai lavorando per un'azienda su un'app interna? Devi dare un'escalation al proprietario e dire "guarda, ho passato x ore su questo e non ho fatto progressi, il vantaggio in termini di costi vale la pena?". Non vuoi andare dal tuo capo e dirgli che hai passato 16 ore su un problema solo per loro, per girarsi e dire, non è così importante, saltarlo per questa versione. devi scoprirlo prima.

• E se ciò non funziona? Bene, le tue uniche opzioni sono di continuare a martellare il problema o cercare l'esperienza nel settore. Chiedi agli esperti di tecnologia su twitter. Invia tramite email il tuo fornitore di tecnologia.

Esci. No, non il tuo lavoro! Alzati e vai a casa. Hai finito per il giorno o il fine settimana. 19 volte su 20 quando si ritorna al problema successivo, la soluzione si presenterà entro un'ora.

Prima che passino le dieci ore, vorrei ottenere un aiuto.

1. Descrivi il problema a qualcun altro, a chiunque altro, anche alla tua anatra di gomma .
2. Chiedi a qualcun altro di dare un'occhiata al codice o di esaminarlo.
3. Isolare. Elimina un po 'di materiale, quindi ripristinalo un po' alla volta fino a quando il problema non riappare.
4. Dormi un po '!

Una parola, timebox , imposta una quantità limitata di tempo per lavorare su qualcosa, e se non è risolto, passa a qualcos'altro e torna ad esso il giorno dopo con una nuova prospettiva.

Questo e un altro paio di occhi valgono sempre più di ogni volta che puoi perdere tempo a fissare qualcosa.

Non spenderei mai più di 45 minuti per un'ora cercando di risolvere qualcosa in una sola seduta, viola la legge dei rendimenti decrescenti.

Spiega il problema a qualcun altro.

Spiegando il problema a qualcun altro, devi chiarirlo: questo spesso ti consente di vedere la soluzione.

(Una delle riviste di computer professionali del Regno Unito una volta propose di vendere ritagli di cartone a grandezza naturale di un programmatore esperto appositamente per questo scopo.)

Trovo che dormire su un problema (a volte anche per un paio di giorni) possa aiutare.

Ho un piano in tre fasi:

1. Prendi un caffè o altra bevanda gustosa.
2. Lavora su qualcos'altro per il resto della giornata.
3. "Telefona a un amico" e scarabocchi sulla lavagna.

Ogni fase è un'escalation se il passaggio precedente non è riuscito. C'è quasi sempre qualcosa di produttivo su cui posso lavorare allo stage 2.

Dormici sopra

Altrimenti, chiama qualcuno vicino e chiedigli di dare una rapida occhiata al codice.

Spesso gli errori che ti richiederebbero molto tempo per trovare (dal momento che è il tuo codice) sono facilmente individuabili da altri

Potresti vedere se alzarti, camminare e pensare al problema ti aiuta a trovare una soluzione. Indipendentemente dal fatto che tu stia effettivamente o stando in piedi o camminando, prova a scappare dal computer mentre stai pensando.

Generalmente faccio uno dei tre:

1. Fai una passeggiata / un giro in bicicletta ... alcuni che ti allontanano dal computer.
2. Gioca con il mio cane o gatto
3. Se hai un hobby, lavora su questo per un po '.

Ognuno dei tre fa un buon lavoro di distrazione dalla situazione in cui si trova. Trovo che le distrazioni permettano al mio cervello subconscio di masticare qualcosa per un po '. Dopo circa un'ora, bam, c'è la soluzione: -).

Costruisci un Harness di test per individuare esattamente il difetto e isolarlo

Continua a eliminare il buon codice ... mentre replichi il difetto. Fino a quando non intendi colpire l'errore nel codice esatto. Quindi traccia il codice.

Lettura consigliata: The Pragmatic Programmer In particolare, Capitolo 10: Bullet Tracer

Tutti questi suggerimenti sono fantastici. Tuttavia, uso una tecnica abbastanza spesso che non ho visto menzionato. Crea elenchi per organizzare i tuoi pensieri sul problema. Se ho un problema particolarmente appiccicoso, di solito scrivo più elenchi come: fatti, ipotesi, domande, sintomi, ecc. Trovo che spesso nel processo di organizzazione delle cose in questo modo scopro ipotesi che non mi ero reso conto di avere ( che spesso si rivelano errate), domande che non ho realizzato devono essere poste, altre permutazioni che posso controllare, ecc.

Modifica:

La risposta breve:

Q: Come gestisci errori davvero bizzarri che ti lasciano perplesso per più di 10 ore?

A: Assicurati che non accadano mai: capisci il tuo design, conosci il tuo codice, impara come usare il tuo debugger.

Spiegazione:

"Dove sembra che un gremlin sia saltato a fondo nei chip e abbia incasinato qualcosa"

Questo non dovrebbe mai accadere. Se è il tuo codice, dovresti avere una buona idea di cosa sta causando l'errore prima di tentare di risolverlo.

Inoltre, quando scrivi il tuo codice dovresti già sapere dove e perché è probabile che fallisca.

Detto questo - chiedi un peer, postando su SO, ripercorrendo e arretrando i tuoi passi e prendendoti una pausa - tutti i suggerimenti sopra menzionati aiuteranno.

L'altra cosa, devi conoscere i tuoi strumenti: il tuo toolkit di debug. Registrazione dei messaggi nei punti sospetti del tuo codice, esaminando attentamente lo stack delle chiamate, utilizzando breakpoint condizionali e orologi, ecc. Le abilità di debug non sono extra: fanno parte della programmazione.

Ho avuto un problema simile, un'apparente corruzione della memoria in Objective-C, con cui ho lottato per molte ore. Ma poi io e i miei colleghi abbiamo fatto una passeggiata per il pranzo, e ho spiegato il problema (e un particolare problema relativo alla deserializzazione di un oggetto nel suo metodo init), e in pratica ho spiegato a me stesso l'intero problema.

(dettagli tecnici: in pratica, ho inizializzato e restituito un oggetto su qualcosa di diverso da self, quindi c'erano due allocazioni, ma solo un oggetto restituito. La memoria si è spostata e impazziva, si blocca e il debugger non sapeva veramente cosa fare con esso sia).

Faiilbagno.

Qualche Rodney McKay fan?

Seriamente, però, se c'è una comunanza tra tutte queste risposte, è prendersi una pausa e fare qualcos'altro .

Mi piace pensarlo come relegando il problema al tuo subconscio. Anche se non siamo inconsapevoli, la nostra mente (sembra) continua a lavorare sul problema, anche quando stiamo facendo qualcos'altro, come fare un bagno .

Attraversalo passo dopo passo, giù in assemblea. Chi chiama cosa, break-point sull'accesso alla memoria. Questo di solito cattura il bug molto velocemente.

Altrimenti, fai una passeggiata.

Una combinazione di tutti questi:

• Scappati da esso per un po 'di tempo in modo che possa sedersi sul tuo backburner. Dormi, riposa, mangia, fai una passeggiata, qualunque cosa.

• Esamina il problema di più, che altro fa di sbagliato, quali altri sintomi puoi trovare?

• Ricerca il problema, vedi cosa puoi trovare. Ricorda di provare parole chiave diverse

• Prova qualcosa di diverso . Un lavoro in giro. Una tecnica di debug diversa. Un validatore Un altro computer.

• Parla con qualcuno . Anche se non sono in grado di aiutare, o nemmeno un programmatore, a volte parlare attiverà l'idea lightbulb

• Riavvia! Se appropriato, prova a riavviare il computer, il server, ecc. Se non altro, puoi usare il tempo per riflettere.

• Chiedi StackOverflow! Siamo qui per aiutarti

Non mi è piaciuta la risposta più votata, perché anche se a volte funziona, qualche volta devi solo capirlo lo stesso giorno, quindi quello che consiglierei, in questo ordine, è:

1. Conferma che non sta succedendo solo a te. Questo può farti risparmiare molto tempo. Forse hai disinstallato un componente richiesto o hai apportato una modifica nel tuo ambiente e un'eccezione viene ingerita da qualche parte nel tuo codice. Se succede solo a te, vorrei utilizzare uno strumento di confronto ambientale. Recentemente ho letto di un software chiamato Envy, che ti permette di fare proprio questo, anche se non è freeware, costa 10 USD.

2. Succede a tutti? Bene, ora esegui una cronologia visualizzazioni sul codice e verifica le modifiche recenti che potrebbero aver causato l'errore, direttamente o indirettamente.

3. Non ci sono modifiche recenti? Se si tratta di un errore molto specifico (un'eccezione), 'stackoverflow it'. Ora ciò non suona meglio di "google it", ma mi sento in diritto di dire che prima ho cercato lo StackOverflow per la ricerca di programmazione rispetto a Google. Se si tratta di un problema noto, è molto probabile che troverai una soluzione qui. In caso contrario, posta una domanda sul relativo sito di stackexchange. Potresti ricevere una risposta molto veloce, o anche se non lo fai, la tua domanda sarà disponibile mentre fai più ricerche. Questo è un vantaggio.

4. Se non hai trovato una risposta online o non si tratta di un errore generale, cammina nel codice passo dopo passo, controllando se i risultati ottenuti da ciascun passaggio hanno senso per il risultato che ti aspetti. Vai dall'inizio alla fine su ciascun metodo e dal basso verso l'alto su una soluzione a più livelli. (Ad esempio, se stai risolvendo le prestazioni, inizia con il codice che recupera i record. Non ha senso iniziare nell'interfaccia utente se puoi determinare rapidamente se il primo passaggio è il problema).

5. Se dopo aver passato il codice un paio di volte non hai ancora trovato ciò che è sbagliato, chiama qualcuno per parlarne. Come qualcuno ha già menzionato, parlarne ad alta voce può accendere la lampadina. Inoltre, la programmazione in coppia è davvero utile.

6. A questo punto, se è fattibile, allontanati per un po 'di tempo o per il giorno. Ho letto ieri un tweet molto sincero che diceva "Sono andato a letto a pensare 'a come va' e mi sono svegliato pensando 'ma ovviamente'". Così vero.

7. Se non hai ancora una risposta, oserei dire che potresti provare a eseguire il refactoring in compiti / metodi / funzioni più piccoli. Henry Ford ha detto qualcosa come "Non c'è un compito così complesso che non può essere realizzato suddividendolo in compiti più piccoli". A questo punto, se la soluzione è troppo complessa e non l'hai capito da solo o con l'aiuto di qualcun altro, rifatta il codice in compiti più piccoli. Anche se non lo finisci, può aiutarti a trovare il motivo.

8. Aggiungi la strumentazione al tuo codice.

9. Tweet su di esso ??

Devi fare un passo indietro. Il mio motto è "se il problema è troppo difficile, allora stai risolvendo il problema sbagliato". Quali sono le tue ipotesi? non fidarti di niente

Il corollario di questo è "il problema più strano, la soluzione più strana". La forza del computer è la sua logica, quindi non puoi vincere sulla logica. Hai un cervello e devi pensarlo fuori.

Nei tempi moderni ci sono così tante altre cose che interagiscono su un sistema: firewall, AV, Antispyware, aggiornamenti automatici che si verificano ogni notte - devi affrontare obiettivi in movimento.

Google it. Stackoverflow it. Pubblicalo nei forum. Fondamentalmente se non puoi risolverlo da solo, fai in modo che le persone ti aiutino.

1. annota il problema.
2. Pensa bene
3. Implementa la soluzione.