Qual è il tuo approccio al debug di un problema transitorio [chiuso]

Quando colpisco un problema del mondo reale davvero doloroso, a volte aiuta a fuggire in una terra di finzione in cui assurde ipotesi possono essere fatte - e quindi a lavorare all'indietro da questo mondo più piacevole.

Quindi, rimodelliamo il tuo problema come uno che ... beh, fa schifo meno con cui avere a che fare.

Diciamo che sai che la prossima volta che questa funzione viene eseguita e qualcuno tenta di stampare un'etichetta, otterrai questo comportamento duplicato. Tuttavia, questo non è un mondo perfetto: non è possibile modificare la richiesta o utilizzare il debug passo dopo passo per risolvere il problema una riga alla volta.

Quindi, come scoprirai che cosa l'ha causato questa volta, quando non puoi semplicemente "rifarlo di nuovo" e farlo accadere di nuovo?

In breve, disconnettendo le tracce dello stack e le informazioni di debug, identificando la domanda più critica a cui è necessario rispondere. Il più ovvio è, come minimo, ciò che viene inviato ESATTAMENTE alla stampante? Viene detto alla stampante una volta di stampare un articolo, o viene ripetuto più e più volte, oppure viene indicato una volta ma con una quantità specificata?

Una "cosa più semplice possibile che potrebbe funzionare" è quella di registrare esattamente ogni singola richiesta di stampa, con l'aspettativa che questo potrebbe essere un grosso log (gestirlo con quello in fase di pianificazione). All'ultimo passaggio prima che una richiesta venga inviata alla stampante, registra esattamente ciò che viene inviato. A seconda dell'implementazione, questo potrebbe significare avvolgere uno streamwriter in un buffer, ecc. - qualunque cosa tu debba fare).

Questo registro dovrebbe consentire di "ristampare" qualsiasi etichetta utilizzando solo le informazioni proprio lì nel registro, quindi puoi semplicemente "inviare nuovamente" la richiesta e farlo funzionare ESATTAMENTE come se la richiesta fosse stata creata dal sistema nel normale la moda.

Quindi, la componente umana - hai bisogno di qualcuno che prenda nota di quando si verifica l'errore, il più vicino al tempo esattamente come quando accade (quindi puoi andare a caccia di una data / ora approssimativa), e persino allegare una delle duplica le etichette sul tuo piccolo "bug report" pezzo di carta con il tempo trascorso. Se potessero prendere nota di ciò che è accaduto prima e di ciò che è venuto dopo, sarebbe ancora meglio - ma questo è ovviamente soggetto a flussi di lavoro che potrebbero essere fuori mano. L'etichetta sospetta e un timestamp approssimativo sarebbero tuttavia estremamente utili.

Quindi cerchi i tuoi file di registro potenzialmente enormi per quell'evento e lo studi. Riattivi quell'etichetta e vedi se succede con quella copia esatta e perfetta della richiesta - o se funziona normalmente. Osservi attentamente ogni byte della richiesta e assicurati che sia perfettamente conforme alle specifiche e come qualsiasi altra richiesta appropriata.

Assicurati che questo sia esattamente ciò che viene inviato alla stampante, anche se devi avere qualcuno che installa un'appliance di rete come un ripetitore invisibile che registra il traffico di rete in modo da poter essere sicuro che funzioni davvero come pensi funziona.

In breve, lo si restringe: la richiesta alla stampante è negativa o no?

Indipendentemente da ciò, imparerai qualcosa da questo. O impari che il software sta rovinando la richiesta, o è "qualcos'altro". Questo sta definendo e limitando l'ambito del problema.

Allora cosa? Bene, puoi sempre provare una stampante diversa, un nuovo computer che genera le richieste, una nuova rete / cavo alla stampante, ecc. La diagnosi tramite scambio di parti è una tradizione consolidata in tutti i campi meccanici:)

Se tutto il resto fallisce, elencare questo risultato duplicato come un "evento raro, approssimativamente una volta al mese", impossibile replicare in modo affidabile, sapere "aggirare le etichette extra", ecc ... dichiarare che è causato da fantasmi, con relativo XKCD :

...eaccettachealcunecosenonsonodestinateaessereconosciutedall'uomo.Ungiornoilproblemascomparirà,nessunosapràilperché,eunabuonastoriadacondividereconiprogrammatoriespertiungiorno,quando"misteri di programmazione inspiegabili" diventerà l'argomento del pranzo.

Supponendo che tu abbia già controllato i registri predefiniti per le eccezioni ...

Spiega il problema al tuo debug duck .

Quando ti fissa in modo assente, vai più in dettaglio. Dì all'anatra come funziona supposto . Se la stupida papera è ancora che ti fissa in modo assente, vai più nel dettaglio su come dovrebbe funzionare.

Mentre spieghi ciascun componente e interazione, chiedi all'anatra se può pensare a qualsiasi motivo (input errato, cattive ipotesi, incompatibilità tra protocollo e comunicazione, o errori in esso) che potrebbe manifestare il problema. Se né tu né l'anatra riescono a pensare a una ragione per cui il componente potrebbe comportarsi male, spostati (per ora).

Ma ad ogni passo durante la tua spiegazione, se hai anche solo un debole sospetto di comportamento scorretto, aggiungi alcuni test alla tua suite.

^{E quando i tuoi colleghi chiedono con chi stai parlando, digli semplicemente: "Oh, non stavo parlando. L'anatra era".}

In ordine di difficoltà:

1. Ricorda che l'errore potrebbe essere fuori dal tuo sistema. Forse qualcuno in contabilità ha presentato la stessa etichetta 10 volte. Esegui il debug del database da cui proviene, ecc. A volte, quando esegui il debug di un test di unità, possono essere necessarie ore per capire che c'è un errore di battitura nei dati di test.

   Leggendo sinceramente il tuo problema, i miei sospetti sono davvero i tuoi componenti   sono funzionanti come progettati, semplicemente, da qualche parte, in qualche modo, stanno ricevendo l'istruzione 10 volte, da qualcosa che non stai considerando attivamente (errore umano, duplicazione che accade da qualche altra parte nel programma, clic umani per 10 volte su uno schermo bloccato, ecc.)

2. Assicurati di stampare l' input del componente che causa l'errore. Quindi puoi riprodurre e testare localmente. Il tuo codice è testabile dall'unità, giusto?
3. Un sacco e molto, molto traccia.
4. Scarica un lotto di informazioni su questo errore. Stampa tutte le tracce dello stack. Crea un dump dell'heap.
5. Se riesci a eseguirlo con successo sul tuo computer locale rapidamente e a riprodurlo in modo temporaneo, fallo e metti un punto di interruzione dove puoi. Quindi puoi guardare il programma molto meglio.
6. Rendi i soliti miglioramenti al codice. Esamina tutti i file colpevoli. Refactatore qualsiasi cosa ti colpisca da pesce o torto. In particolare, vedi il mio primo punto e refactoring dei tuoi componenti buggy in modo che abbiano input isolati e siano più testabili. Questo è simile a pulire la tua stanza finché non trovi le tue chiavi.

Vorrei cercare un modo per rilevare i duplicati all'interno del codice, controllarlo a vari livelli di astrazione e registrare quando si verifica. È possibile richiedere l'invio di un numero di sequenza a ciascun lavoro o allegare un timestamp a un lavoro o controllare un hash. In questo modo se rilevi un duplicato al livello 3, ma non al livello 2, hai ristretto i criteri di ricerca.

L'altro vantaggio di questo approccio è che puoi spesso aggirare il sintomo prima ancora di conoscerne la causa. Supponendo che tu possa dire la differenza tra duplicati avviati dall'utente e duplicati di bug, puoi semplicemente sopprimere i duplicati quando vengono rilevati dopo il fatto. Questa non è una soluzione ideale, ma è meglio che lasciare il problema per mesi o anni, soprattutto se ora i duplicati vengono catturati solo dall'ispezione manuale.