blocco debugger

Question

Ti capita mai di imbattersi in un bug in cui sei appena fuori dalle idee e non sai cosa provare dopo, e ti stai annoiando davvero? Ci sono idee generali su come uscire da questa modalità?

Answer 1

Quando sono bloccato in questo modo, il miglior consiglio che ho trovato è lasciare per un po '. Che si tratti di un pranzo lungo o di una giornata intera. Torna fresco e dai un nuovo sguardo. La maggior parte delle volte la risposta ti starà a guardare in faccia. Finora una pausa caffè di 10 minuti non è stata abbastanza per me, ma il tuo chilometraggio può variare.

Secondo, parla con i tuoi colleghi. Attraversa tutto ciò che hai provato. Chiedi loro di ascoltare, e mentre stai parlando, molte volte, la risposta verrà da te.

Questi sono solo i due che uso più spesso quando eseguo il debug dei blocchi.

Answer 2

Di solito faccio una pausa ... se non funziona, dormo sul problema. (In realtà, per essere onesti, dovrei dire che trascorro una notte insonne a rimuginare sul problema).

Quasi sempre ho una lista di possibili soluzioni pronte al mattino. :-)

Answer 3

Io di solito fare qualche passo:

• un'occhiata al codice che è coinvolto nella funzionalità che ha i bug e luogo messaggi logger in un modo che mi aiuterà a ridurre il problema (questo permette di guardare il registratore in seguito, quando non si è più che infastidito, e magari trovare suggerimenti utili: P)
• chiedere ai miei colleghi di alto livello per i suggerimenti
• chiamata al cliente di avere una chiara comprensione di quando il problema nasce

Answer 4

Di solito mi trovo in quello stato d'animo quando non ho adottato un approccio strutturale dall'inizio. Restringendo in modo iterativo l'area in cui il problema può vivere e cercando di scrivere il codice più piccolo in grado di riprodurre l'errore, non ho ancora fallito.

Answer 5

Penso che se si esegue in questo tipo di problema è il momento di fare un po 'seria refactoring ...

Inoltre potrebbe indicare presupposti falsi. Prova ad assumere programmaticamente tutto ciò che stai 'solo' assumendo. Controllate che nessun invariante di metodo sia rotto da nessuno dei metodi presenti nello stack.

Answer 6

Altri hanno detto di prendersi una pausa o "dormirci sopra". Questa tecnica è conosciuta come (tra le altre cose) l'incubazione. Una volta che abbracci l'idea, puoi farlo anche di più.

Un aspetto importante da lasciare davvero il problema, fiducioso che avrai risposte più tardi. Il pericoloso altrimenti, specialmente se dormi su di esso, è che ti preoccuperai fino all'ultimo, poi questo diventa un ciclo infinito che la tua mente viene catturata durante la notte. Probabilmente finirai per svegliarsi non troppo riposato dopo aver sognato molti sogni circolari. Fai questo troppo ed è un percorso verso la depressione.

Answer 7

• Cinque minuti di pausa

Assolutamente critica, per non distruggere il vostro tastiera.

• spiegare il problema in un'email a tua sorella

O il vostro figlio di due anni. Qualcuno che wouldn't understand a word * a meno che non l'abbia spiegato molto chiaramente. Non è necessario inviare l'e-mail, devi solo essere certo di capirlo a fondo. Rimarrai sorpreso da quante volte il semplice riaffermare il problema ti rende improvvisamente ovvio dove hai sbagliato. Questo è un buon modo per scoprire quali sono le tue ipotesi riguardo al problema e come potrebbero non essere necessariamente corrette.

* Questo collegamento è una risposta eccellente di JaredPar su una diversa domanda SO.

• Parla con un collega

A questo punto hai gia 'inviato via email' l'animale domestico della famiglia, in modo da sapere che hai spera coperto tutti gli aspetti stupidi, è il momento di parlare a una persona reale. Potrebbero aver vissuto qualcosa di oscuro in passato che ricorda loro questa situazione, e avranno sicuramente una prospettiva diversa. Cerca di essere sicuro di quale sia il problema, non di quello che stai pensando . Non vuoi forzarli. Puoi e dovresti parlare di ciò che hanno provato e spiegare perché pensi che il problema sia in quella zona (probabilmente hai ragione) ma non vuoi chiudere la tua mente ai loro suggerimenti, anche se non lo fanno sembra giusto

• guardare il codice di nuovo

A questo punto, si spera, dovrebbe essere meno violento, e si dovrebbe essere armati con nuove idee. Inizia ri-verificare il bug. Un semplice passaggio, ma sono stato frustrato per ore in un bug presente nel nostro script di test e non nel nostro codice. Una volta verificato nuovamente il bug, inizia in alto. Verifica TUTTO. Metti un punto di interruzione all'ultimo punto in cui sei sicuro al 100% e poi prosegui fino a quando non trovi che l'uscita è interrotta di nuovo. Questo è un enorme successo perché ora hai un blocco di codice, sperabilmente più piccolo da investigare. Quindi, se necessario, richiama un collega per esaminare il codice corrente in esecuzione.

Answer 8

Un'altra buona opzione è far rimbalzare le idee su altri sviluppatori/membri del team. A volte ti faranno delle domande che non hai considerato.

Se lavori da solo, è una buona idea avere alcuni colleghi sviluppatori a cui puoi chattare per risolvere i problemi con approcci diversi. Saresti stupito di quanto spesso una nuova prospettiva possa essere la svolta di cui hai bisogno.

Answer 9

Prova David Ungars "Doccia Metodologia":

"Se sapete cosa scrivere, tipo Se non sai cosa scrivere, fare una doccia e rimanere sotto la doccia finché non si sa cosa scrivere. "

Questo tipo di convocazione su ciò che la maggioranza ama fare. Fare una pausa ! Non importa che tipo di rottura sia, purché tu non pensi alle cose che stavi facendo prima della pausa. La distrazione in qualsiasi forma è buona.

Cheers!

Answer 10

Di solito faccio un passaggio a vuoto attraverso il metodo/la funzione incriminata, passo dopo passo.E non dare per scontato che il bug arrivi da lì, potrebbe provenire da qualsiasi parte prima.

Utilizzare un debugger appropriato, non utilizzare una serie di printfs.