Dove iniziare a correggere un bug complesso?

Non iniziare facendo modifiche, inizia riproducendo il bug nei test unitari. Dopo di ciò cambia il codice in modo che il test dell'unità passi invece di fallire.

Sembra che tu abbia più bug, non solo uno, inizi al livello più basso, identifichi bug specifici, scriva errori di unit test e risolvi.

Per prima cosa, analizza il problema. Non iniziare a fare cambiamenti finché non comprendi il codice base. Inizia leggendo la documentazione di progettazione (classe, sequenza e diagrammi di comunicazione sarebbe un buon inizio) e nei commenti di codice. Usa la registrazione (questo è il tipo di registrazione di livello TRACE e DEBUG), un debugger per scorrere il codice e guardare le variabili mentre cambiano. Questo è anche un buon momento per prendere appunti se la documentazione di progettazione e / o i commenti nel codice sono sbagliati - risolvili per gli sviluppatori futuri.

In secondo luogo, una volta compreso il codebase, trovare i casi di test per identificare il problema e confermare di averlo risolto. Potrebbero esserci test unitari, test di sistema e test di accettazione associati al problema che è necessario creare o revisionare. Dovrai assicurarti di aver corretto il difetto, che le tue correzioni non introducano altri difetti e che questo difetto non ricompaia come risultato di una regressione.

Infine, puoi correggere il difetto. Esegui i test per confermare e, se la documentazione è interessata, aggiornala o presenta un difetto contro la documentazione in modo che eventuali modifiche apportate vengano applicate all'utente o ai futuri sviluppatori.

the problem seems to be coming from a lot of places

Fortunatamente, questo è probabilmente falso. I bug possono essere causati da ogni sorta di cose diverse, ma quando vedi spuntare un bug dappertutto, puoi scommettere che tutte le istanze di quell'errore riportano tutte a un posto. In questa posizione potrebbero essere presenti dati danneggiati in una tabella SQL, un'ambientazione funky in un file di configurazione o una parte di cattiva logica dell'applicazione a cui molti componenti toccano. Potrebbe anche essere un milione di altre cose, ma la chiave è sempre capire quali sono le diverse istanze del bug in comune. Gli strumenti possono essere di grande aiuto. Utilizzare un profiler SQL per i dati pesanti. Recentemente ho dovuto risolvere un sistema proprietario che aveva circa 15.000 stored procedure. Uno di questi è andato in tilt durante un aggiornamento in conflitto con alcune delle modifiche apportate al sistema. Senza un profiler SQL, questa soluzione sarebbe stata più o meno impossibile. Se si esclude un problema relativo ai dati, l'obiettivo numero uno è trovare la riga di codice in cui viene creato il bug. Con un buon registro di tracciamento, un debugger e un po 'di buon senso, puoi rintracciare qualsiasi errore.

Per risolvere complessi bug multipli ("provenienti da molti punti"):

Questo è l'approccio generale provato e testato che prendo:

• Prendi la sezione del code-base in questione
• Rompi questa sezione in sottosezioni
• Usando un set iniziale di dati di input, sovrapponi questi dati / eventi attraverso questa sotto sezione di codice isolata. Devi dimostrare che l'atteso "effetto" (valori / eventi di ritorno) corrisponde a quello che ti aspetti. Se questo non riesce a risolverlo fino a quando non lo fa
• ripeti sopra per la prossima sottosezione utilizzando gli "effetti" (valori restituiti / eventi) dalla sottosezione precedente
• Una volta completate tutte le sottosezioni, il riassemblaggio delle sottosezioni dovrebbe ora risolvere tutti i bug multipli

1) STOP !!!

2) Modalità debug ON

3) Prova a riprodurre l'errore

4) Controlla log e debugger

5) Modifica il codice di conseguenza

6) Prova a riprodurre nuovamente lo stesso bug

7) Torna al punto 3 a meno che il bug sia stato corretto.

Da ora in poi, includerai questo particolare bug test insieme ai tuoi altri test, perché vuoi essere certo che non verrà più visualizzato. Dimentica "Ma non succederà più!" .