Suggerimenti per il debug con pochissime informazioni? [chiuso]

Quando ottengo qualcosa del genere, di solito richiedo più informazioni. Non so come sia dove lavori, ma qui se non ho abbastanza informazioni per riprodurre il problema localmente, posso rispedire indietro il biglietto contrassegnato come Non riesco a riprodurre, con una richiesta di ulteriori informazioni, e sanno che non è stato risolto nulla fino a quando Sono in grado di romperlo dalla mia parte.

Se i tuoi clienti hanno problemi con la descrizione dei passaggi, chiedi loro un video di screencap. Ci sono alcuni prodotti gratuiti che possono crearli, come Jing. Rende molto più facile quando puoi guardare esattamente quello che stavano facendo.

EDIT: Jing è stata una buona idea quando ho scritto questo alcuni anni fa. Da allora, hanno modificato il loro programma di installazione per caricare il sistema con crapware "bonus" che non hai mai richiesto, quindi non posso più raccomandarlo. Tuttavia, ci sono un sacco di registratori video decenti in giro.

Un buon inizio potrebbe essere questo libro .

Sto usando la definizione di seguito perché sembra che lo sviluppatore non sia in giro per supportarlo più.

Legacy code is source code that relates to a no-longer supported.

Ho avuto un problema simile qualche anno fa e il più grande incremento della produttività e della pulizia del codice è stato l'integrazione del bug tracking nel sistema.

Abbiamo usato Fogbugz (presumo che facciano ancora Fogcreek!) e siamo stati in grado di creare un meccanismo di gestione delle eccezioni in cui l'utente poteva premere un pulsante ogni volta che veniva sollevata un'eccezione e si sarebbe immediatamente loggato nel nostro sistema - no più chiamate e niente più screenshot. Con questa opzione prendi le informazioni di cui hai bisogno invece di provare ad estrarle dall'utente. Suoni come una variante ti farebbero del bene, specialmente con l'opzione di acquisizione dello screenshot.

L'altra cosa che vuoi iniziare a fare è iniziare ad aggiungere la registrazione. Si consiglia di andare fino alla registrazione di ogni chiamata di metodo con valori argomento. Poiché sembra che tu stia lavorando con codice legacy (codice senza test), questa registrazione ti aiuterà ad aggiungere i test unitari appropriati per non ripetere alcun problema.

Il mio consiglio più sincero è di iniziare il refactoring dove è possibile. Non riesco a contare il numero di volte in cui ho visto una ricapitolazione di funzionalità solo per scoprire che non era al 100% una copia completa. Era una copia del 99,9% e un piccolo errore minore che causava un bug. Inizia ad aggiungere test unitari a tutto e se disponi di un reparto QA prova a ottenere alcuni script di test automatici per quelle parti del codice che stai utilizzando.

D'altra parte, vedi quanto tempo di accesso può essere inserito nel codice. Cioè, se non ha molto nel modo di logging è possibile aggiungere un flag al codice per iniziare a raccogliere più logging dettagliato per i propri scopi di debug. Questo è qualcosa che puoi attivare e disattivare un utente se riesci a far funzionare una finestra di dialogo. Mi ha aiutato più volte di quanto possa contare. Normalmente ottengo "non funziona" senza un'immagine del problema. Dico "inviami il file di registro"

Inizia scrivendo i test unitari. Scegli una classe o una funzione e scrivi una serie di test corrispondenti a come pensi che dovrebbe funzionare. Se i test falliscono, capire perché. Se è un bug, risolvilo. Se le tue aspettative si rivelano sbagliate, scopri cosa fa effettivamente la cosa e modifica i test di conseguenza.

Una volta ottenuto un discreto set di test di unità di lavoro, si dispone di una rete di sicurezza per eseguire alcuni refactoring per rendere il codice più pulito.

Continua a ripetere finché non comprendi il codice base.

Inutile dire che questo è qualcosa che dovresti fare prima del tempo, non in risposta a una segnalazione di bug.