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

Li conosci, quegli errori che NON hanno senso. Dove sembra che un gremlin sia appena saltato in profondità nelle tue chips e abbia incasinato qualcosa. Fai una passeggiata, scrivi cose, chiami uno zio?

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. Bevi un caffè, parla di qualcosa di estraneo a un collega. Spingi il problema fuori di testa. Quando si osserva il problema 5 o 10 minuti dopo, lo si osserva da una prospettiva leggermente diversa. Il più delle volte funziona.

• In questo caso no. Quindi passa altri 10-30 minuti a guardarlo. Quindi chiama un collega. Ma prima di farlo, prendi delle note; vuoi dimostrare il problema, riprodurlo, quindi elencare le cose che hai provato e, soprattutto, dimostrare di averle provate. Quindi prima fai una corsa a secco. Imposta alcuni segni di libro nel codice, chiudi tutti i documenti aperti superflui ecc. In questo modo puoi risolvere tu stesso il problema o quando lo dimostrerai non perderai tempo.

• Chiedi al tuo collega di farti provare tutti i tuoi presupposti. quel setter viene effettivamente invocato? Quel metodo sta davvero restituendo ciò che affermi di essere? Pensi che l'oggetto non sia nullo - mostra loro che non è nullo.

• Il più delle volte, dimostrare il problema ti farà capire che non hai provato tutte le possibilità o che il tuo collega vedrà il tuo errore.

• Se non funziona, è il momento 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. A questo punto probabilmente non otterrai una risposta, ma stai cercando idee, possibilità, modi diversi di affrontare il problema.

• Fai qualcos'altro, se hai trascorso 5 ore su un problema è tempo di lasciarlo per un altro giorno. Forse otterrai una risposta utile. Forse quando attaccherai il problema il giorno successivo sarà ovvio.

• Se nulla di tutto ciò 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? Lavori per un'azienda su un'app interna? Devi inoltrare questo al proprietario e dire "guarda, ho trascorso x ore su questo e non ho fatto progressi, ne vale la pena il vantaggio in termini di costi?". Non vuoi andare dal tuo capo e dire loro che hai trascorso 16 ore su un problema solo per loro di voltarsi e dire, non è così importante, saltalo per questa versione. devi scoprirlo prima.

• E se non funziona? Bene, le tue uniche opzioni sono di continuare a risolvere il problema o cercare competenze nel settore. Chiedi agli esperti di tecnologia su Twitter. Invia un'email al tuo fornitore di tecnologia.

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

Prima che passino dieci ore, avrei bisogno di aiuto.

1. Descrivi il problema a qualcun altro, a chiunque, anche alla tua papera di gomma .
2. Chiedi a qualcun altro di dare un'occhiata al codice o di esaminarlo con loro.
3. Isolalo. Elimina un sacco di cose, quindi riportale un po 'alla volta fino a quando il problema riappare.
4. Dormire un po!

Una parola, timeboximposta un periodo di tempo limitato per lavorare su qualcosa e, se non viene risolto, passa a qualcos'altro e torna al giorno successivo con una nuova prospettiva.

Questo e un altro set di occhi, vale sempre più di ogni volta che puoi sprecare a fissare qualcosa.

Non passerei mai più di 45 minuti a 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, è necessario chiarirlo: questo spesso consente di vedere la soluzione.

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

Trovo che dormire su un problema (a volte per un paio di giorni) possa anche 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 scarabocchia sulla lavagna.

Ogni fase è un'escalation se il passaggio precedente non è riuscito. C'è quasi sempre qualcos'altro di produttivo su cui posso lavorare nella fase 2.

Dormici sopra

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

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

Potresti vedere se alzarti, camminare e pensare al problema ti aiuta a trovare una soluzione. Indipendentemente dal fatto che tu sia effettivamente in piedi o in movimento, prova ad allontanarti dal computer mentre stai pensando.

In genere faccio una delle tre:

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

Ognuno dei tre fa un buon lavoro per distrarsi dalla situazione attuale. Trovo che le distrazioni lasciano che il mio cervello subconscio mastica qualcosa per un po '. Dopo circa un'ora, bam, c'è la soluzione :-).

Costruisci un cablaggio di prova per colpire quel difetto esatto e isolarlo

Continua a eliminare il buon codice .. durante la replica del difetto. Fino a quando non si prende di mira l'esatto pezzo di codice che contiene l'errore. Quindi traccia il codice.

Letture consigliate: il programmatore pragmatico in particolare il capitolo 10: proiettili di tracer

Tutti questi suggerimenti sono fantastici. Tuttavia, utilizzo 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 avevo realizzato di avere ( che spesso si rivelano errati), domande che non ho realizzato devono essere poste, altre permutazioni che posso controllare, ecc.

Modificare:

La breve risposta:

D: Come affronti errori davvero bizzarri che ti tengono perplesso per più di 10 ore?

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

Spiegazione:

"Dove sembra che un gremlin sia appena saltato in profondità nelle tue chips e abbia incasinato qualcosa"

Questo non dovrebbe mai succedere. Se è il tuo codice, dovresti avere un'ottima idea di cosa sta causando l'errore prima di provare a risolverlo.

Inoltre, quando scrivi il tuo codice dovresti già sapere dove e perché probabilmente fallirà.

Detto questo - chiedere a un collega, pubblicare su SO, ripercorrere e tornare indietro sui passi e fare una pausa - tutti i suggerimenti sopra menzionati aiuteranno.

L'altra cosa è che devi conoscere i tuoi strumenti: il tuo toolkit di debug. Registrare i messaggi in punti sospetti nel codice, esaminare attentamente lo stack di chiamate, utilizzare punti di interruzione e orologi condizionali, ecc. Ecc. Le abilità di debug non sono extra: fanno parte della programmazione.

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

(dettagli tecnici: fondamentalmente, ho inizializzato e restituito un oggetto a qualcosa di diverso da sé, quindi c'erano due alloc, ma solo un oggetto restituito. La memoria si spostava e impazziva, si arresta in modo anomalo e il debugger non sapeva davvero cosa farne neanche).

Fai un bagno.

Qualche fan di Rodney McKay ?

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

Mi piace pensarlo come relegare il problema al tuo subconscio. Anche se altrimenti non lo sappiamo, le nostre menti (sembrano) continuano a lavorare sul problema, anche quando stiamo facendo qualcos'altro, come fare un bagno .

Attraversalo passo dopo passo, giù nell'assemblaggio. Chi chiama cosa, punto di rottura sull'accesso alla memoria. Questo di solito cattura il bug molto velocemente.

Altrimenti, fai una passeggiata.

Una combinazione di tutti questi:

• Allontanati da esso per un po 'in modo che possa sedere sul tuo bruciatore posteriore. Dormi, riposa, mangia, fai una passeggiata, qualunque cosa.

• Esamina ulteriormente il problema, cos'altro fa di sbagliato, quali altri sintomi puoi trovare?

• Cerca il problema, vedi cosa riesci a trovare. Ricorda di provare diverse parole chiave

• Prova qualcosa di diverso . Una soluzione. Una diversa tecnica di debug. Un validatore. Un computer diverso.

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

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

• Chiedi a StackOverflow! Siamo qui per aiutare

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

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

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

3. Non ci sono cambiamenti recenti? Se si tratta di un errore molto specifico (un'eccezione), "stackoverflow it". Ora non suona meglio di "google it", ma mi sento bene a dire che prima cerco lo stackoverflow per la ricerca di programmazione di google. Se si tratta di un problema davvero noto, è molto probabile che troverai una soluzione qui. In caso contrario, pubblica una domanda sul sito stackexchange correlato. Potresti ottenere una risposta molto rapida, o anche se non lo fai, la tua domanda sarà disponibile mentre fai ulteriori ricerche. Questo è un vantaggio.

4. Se non hai trovato una risposta online o non si tratta di un errore generale, segui il codice passo dopo passo, controllando se i risultati ottenuti di ogni 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 si stanno risolvendo i problemi relativi alle prestazioni, iniziare con il codice che recupera i record. Non ha senso iniziare nell'interfaccia utente se è possibile determinare rapidamente se il primo passaggio è il problema).

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

6. A questo punto, se è possibile, vai via per un po 'di tempo o per il giorno. Ieri ho letto un vero tweet che diceva "Sono andato a letto pensando" 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 del tipo "Non esiste un compito così complesso che non può essere realizzato suddividendolo in compiti più piccoli". A questo punto, se la soluzione è troppo complessa e non hai capito da solo o con l'aiuto di qualcun altro, trasforma il codice in attività più piccole. Anche se non finisci per impegnarti, può aiutarti a trovare il motivo.

8. Aggiungi la strumentazione al tuo codice.

9. Tweet a riguardo ??

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

Il corollario è "più strano è il problema, più strana è la soluzione". Il punto di forza del computer è la sua logica, quindi non puoi vincere con la logica. Hai un cervello e devi pensarci troppo.

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

Google. StackOverflow. Pubblicalo sui forum. Fondamentalmente se non riesci a risolverlo da solo, chiedi aiuto alle persone.

1. Scrivi il problema.
2. Pensare a fondo.
3. Implementa la soluzione.