Suggerimenti per il debug con pochissime informazioni? [chiuso]

Ho ereditato un progetto con una base di codice abbastanza grande e lo sviluppatore originale raramente, se non mai, risponde alle e-mail. Ci sono un sacco di modi diversi per fare alcune cose in esso, e non le conosco tutte. Un sacco di codice duplicato lungo questi percorsi (piuttosto che funzioni incluse da, diciamo, 5 pagine che fanno relativamente la stessa cosa, è un codice copiato su 5 pagine) e alcuni problemi sottili nel database (abbiamo tutti sentito parlare di spaghetti code , ma hai mai sentito parlare di un database di spaghetti?)

Tutto ciò di cui posso occuparmi il più delle volte senza problemi.

Il problema è quando un client trova un bug da qualche parte. Di solito inviano uno screenshot del problema finale e dicono "Potresti dare un'occhiata a questo?" mettendo in evidenza la cosa specifica sulla pagina che è sbagliato, e talvolta ciò che era previsto. Vengono fornite pochissime informazioni e cercare di parlare con loro e ottenere di più (come quello che hanno fatto per ottenere il risultato) è come tirare i denti.

Fondamentalmente, si riduce a questo:

• Base di codice ampia e complessa che non conosco al 100%
• In molti modi le cose possono andare storte
• Pochissime informazioni su come è nato un bug

Qualcuno ha suggerimenti, trucchi, suggerimenti, ecc. Su come eseguire il debug di questo genere di cose?

Quando ricevo qualcosa del genere, di solito chiedo ulteriori informazioni. Non sono sicuro di dove lavori, ma qui se non ho abbastanza informazioni per riprodurre il problema localmente, posso rispedire il biglietto contrassegnato Impossibile riprodurre, con una richiesta di ulteriori informazioni, e sanno che nulla viene risolto 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 screencap. Ci sono alcuni prodotti gratuiti che possono crearli, come Jing. Rende molto più facile quando puoi vedere esattamente cosa stavano facendo.

EDIT: Jing è stata una buona idea quando l'ho scritta alcuni anni fa. Da allora, hanno modificato il loro programma di installazione per caricare il tuo sistema con crapware "bonus" che non hai mai richiesto, quindi non posso più consigliarlo. Ci sono molti registratori di schermo decenti in giro, però.

Un buon inizio potrebbe essere questo libro .

Sto usando la definizione di seguito in quanto sembra che lo sviluppatore non sia più in giro per supportarla.

Il codice legacy è un codice sorgente correlato a un non più supportato.

Ho avuto un problema simile qualche anno fa e la spinta maggiore alla produttività e alla pulizia del codice è stata l'integrazione del tracciamento dei bug nel sistema.

Abbiamo usato Fogbugz (suppongo che facciano ancora Fogcreek!) E siamo stati in grado di costruire 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 registrato nel nostro sistema - niente più chiamate e non più screenshot. Con questa opzione prendi le informazioni di cui hai bisogno invece di provare a estrarle dall'utente. Sembra una variante che ti farebbe del bene, soprattutto con un'opzione di acquisizione screenshot.

L'altra cosa che vorresti iniziare a fare è iniziare ad aggiungere la registrazione. Potresti voler arrivare fino alla registrazione di ogni chiamata di metodo con valori di argomento. Poiché sembra che tu stia lavorando con un codice legacy (codice senza test), questa registrazione ti aiuterà ad aggiungere test unitari appropriati in modo da non ripetere alcun problema.

Il mio consiglio più serio è di iniziare il refactoring dove è possibile. Non riesco a contare il numero di volte in cui ho visto una copia della funzionalità solo per scoprire che non era al 100% una copia completa. Era una copia del 99,9% e 1 piccolo, piccolo errore che ha provocato un errore. Inizia ad aggiungere unit test a tutto e se hai un dipartimento di controllo qualità prova a ottenere alcuni script di test automatizzati per quelle parti del codice che stai lavorando.

D'altra parte, guarda quanta registrazione puoi iniettare nel codice. Cioè, se non ha molto in termini di registrazione, è possibile aggiungere un flag al codice per iniziare a raccogliere più registrazioni dettagliate per i propri scopi di debug. Questo è qualcosa che puoi far attivare e disattivare se un utente può avviare una finestra di dialogo. Mi ha aiutato più volte di quante ne possa contare. Normalmente ottengo "non funziona" senza un'immagine del problema. Dico solo "inviami il file di registro".

Inizia scrivendo unit test. 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, correggilo. Se le tue aspettative si rivelano errate, scopri cosa fa effettivamente la cosa e modifica i test di conseguenza.

Una volta che hai una serie decente di test dell'unità di lavoro, hai una rete di sicurezza per fare un po 'di refactoring per rendere il codice più pulito.

Continua a ripetere finché non capisci la base di codice.

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