Immagina questo scenario: Sei relativamente nuovo a un codebase molto grande per un'applicazione GUI. Arriva una segnalazione di bug. Poiché si tratta di una GUI, il report non è espresso in termini relativi a funzioni o eccezioni sollevate dal codice, ma ha schermate della GUI, descrizioni, forse un video.
Quali strategie usi per identificare il codice pertinente?
Si noti che questo non ha nulla a che fare con la qualità della segnalazione di bug; possiamo supporre che sia molto buono.
Prima riproduci il bug. Quindi esegui il tuo sistema nel debugger e fermati in un punto in cui sai che il flusso di controllo passerà. I frame dello stack a quel punto indicano quale percorso attraverso il sistema prende questo case d'uso.
Ovviamente il punto importante è scegliere un posto nella base di codice che sia il più vicino possibile al punto del problema. Se il problema riguarda la GUI stessa (ad es. Etichetta errata su un pulsante), devi fermarti da qualche parte all'interno del codice della GUI. Se è il risultato di un'operazione, il problema si verifica molto più tardi, quando i dati vengono effettivamente elaborati e i risultati vengono consegnati. Se un errore è profondo nella logica di elaborazione, potresti persino essere in grado di riprodurlo semplicemente dando diversi input a un test di unità esistente e rinunciare a eseguire il sistema live del tutto (tranne per verificare che puoi riprodurre il problema in primo luogo, ovviamente).
Bisettrice della ricerca. Hai qualche input che porta a un risultato inaspettato. Probabilmente c'è una grande quantità di codice coinvolto nel passaggio dall'input all'output. Devi avere un'idea approssimativa degli strati e delle operazioni coinvolte. Quindi scegli un punto da qualche parte nel mezzo di questo, e determina se l'output atteso è già sbagliato a questo punto. Questo taglierà l'area del possibile bug a metà. Fai questo alcune volte e hai isolato il bug.
Inizia dai confini tra i sottosistemi. Ad esempio, se si dispone di un'API REST è facile eseguire una richiesta e ispezionare il risultato. Se è coinvolto SQL, è facile eseguire SQL e ispezionare il risultato. Ovunque tu abbia un'interfaccia ben specificata, è più facile controllare l'input rispetto all'output.
Dal tuo commento,
In a application with say ~10k source files, finding this place is the problem
In un'applicazione di queste dimensioni, dovrebbero esserci alcune opzioni di registrazione / tracciamento incorporate nell'applicazione. Questo è quasi un requisito per applicazioni di queste dimensioni, incluse le GUI.
Tra le opzioni di registrazione / traccia, una delle opzioni dovrebbe essere quella di stampare la posizione, il nome della classe o il nome della funzione del codice che viene eseguito, anche se il codice in esecuzione pensa che tutto vada normalmente (senza eccezione). A seconda di come viene effettivamente utilizzata la registrazione nell'intera applicazione, potrebbe essere necessario aumentare il livello di registrazione su DEBUG o VERBOSE.
Il codice che non rileva una condizione anomala quando uno è realmente accaduto è di per sé un difetto del software. Inoltre, a volte l'attuale comportamento del software è esattamente come previsto dal programmatore, tranne che non concorda con i requisiti o le specifiche dell'utente. In entrambi i casi, vorrai vedere la traccia di esecuzione, non solo il rapporto delle eccezioni.
Abilitarlo e vedere dove colpisce l'esecuzione mentre esegui i passaggi di riproduzione del bug. Utilizza i log come punto di partenza per ulteriori indagini.
Se l'applicazione non implementa una registrazione / traccia adeguata per consentirvi di indagare sul bug, portate questo problema al responsabile del progetto. Se l'applicazione non ha alcuna registrazione / traccia, suppongo che il problema sia più grande della base di codice stessa e richiederà più persone per risolverlo.
Una strada da percorrere sarebbe quella di recuperare il maggior numero possibile di informazioni dai report (il report video è molto utile) e provare a riprodurre il bug. Puoi comunque utilizzare i punti di interruzione dal primo metodo richiamato dal tuo pulsante e da lì puoi approfondire. La mia raccomandazione sarebbe quella di identificare il punto di ingresso (ad esempio una classe principale) per la tua app. In base alla mia esperienza, il modo migliore è riprodurre il bug nell'app in esecuzione.
Leggi altre domande sui tag debugging bug-report