Debug: comprendere i dettagli sul motivo per cui alcune correzioni hanno funzionato? [chiuso]

Durante il debug, a volte scopro di apportare alcune modifiche e non sono sicuro al 100% del motivo per cui tali modifiche correggono alcuni bug nel programma. È essenziale comprendere ogni singolo dettaglio sul perché si stavano verificando alcuni bug e perché alcuni cambiamenti hanno eliminato tali bug? O è comune tra gli sviluppatori a volte far funzionare il programma senza conoscere veramente i dettagli sul perché la correzione ha funzionato?

Direi che è essenziale comprendere ogni singolo dettaglio sul perché si stessero verificando alcuni bug e perché alcuni cambiamenti abbiano eliminato quei bug, ed è anche comune tra gli sviluppatori a volte far funzionare il programma senza conoscere veramente i dettagli sul perché la correzione ha funzionato!

L'arte di cambiare le cose fino alla scomparsa di un bug, senza capire cosa lo abbia causato o perché il cambiamento lo abbia corretto, viene spesso chiamata "programmazione voodoo" e non è un complimento. Non c'è davvero alcun modo in cui tu possa essere sicuro di aver veramente corretto un bug, invece di risolverlo parzialmente per il caso particolare che stavi investigando, se non capisci cosa lo abbia causato.

Nel peggiore dei casi, non hai fatto nulla tranne spostare il bug: ricordo dal primo anno di calcolo presso uni, quando molti studenti stavano imparando la C e i puntatori per la prima volta, i bug dei puntatori spesso smettevano di manifestarsi quando cambiavano le cose casualmente, perché le modifiche riorganizzerebbero le strutture di dati in memoria abbastanza da far calpestare il bug del puntatore su un diverso bit di memoria. Ovviamente ciò non ha aiutato affatto .

Ma detto questo, le realtà commerciali della programmazione sono spesso tali da soddisfare il cliente che un bug è stato risolto è più importante che soddisfare te stesso. Non ti consiglierei mai di dichiarare qualcosa risolto se non avessi idea di cosa lo abbia causato, ma se riesci a vedere che un po 'di codice era problematico e lo hai rielaborato, anche se "non sei sicuro al 100%" di come ciò abbia causato lo specifico bug da manifestare, a volte basta passare al bug successivo prima che il client urli troppo forte sui tuoi lenti progressi.

Se ritieni che un client sia pazzo del fatto che ci vuole troppo tempo per correggere un bug, immagina quanto saranno pazzi per un bug ricorrente che hai sostenuto sia stato risolto, o una correzione per una cosa che peggiora qualcos'altro. Se la tua correzione è solo una soluzione alternativa o mitigazione, i clienti di solito la apprezzeranno comunque, ma devi essere onesto su ciò che è e hai messo tutta la registrazione di cui hai bisogno per risolverla davvero.

Se sei abbastanza sicuro di averlo riparato, ma non sai perché la correzione funziona, chiedi a qualcuno. La maggior parte degli ingegneri che conosco amano ricevere domande del genere a causa del mistero che c'è dietro.

Cambiare roba fino a quando il bug non è più non c'è generalmente cattiva pratica, ma sfortunatamente una realtà per alcune persone.

Sono fermamente convinto che non dovresti mai scrivere codice che non capisci cosa fa o perché lo fa. Come puoi essere sicuro che, anche se hai corretto il bug che hai deciso di risolvere, non hai rotto altro?

In genere, prima di correggere un problema / errore, è necessario eseguire una valutazione / analisi della causa sottostante per determinare il motivo per cui si sta verificando il problema e se è possibile replicarlo. Quindi dovresti leggere il codice e capire perché il codice causa l'errore. Una volta che hai capito: puoi iniziare a vedere come risolvere il problema e determinare altre aree che avranno effetto sulle tue modifiche. I test unitari possono davvero aiutare qui!

Ho visto una serie di modifiche al codice che le persone hanno apportato per risolvere un problema (il che è fantastico), ma sfortunatamente ha introdotto altri problemi perché lo sviluppatore non era a conoscenza del pieno impatto di ciò che è cambiato. Molte di queste "correzioni" oscurano solo la causa alla base del problema originale, oltre a introdurre complessità e altri bug.

Detto questo, ho risolto una serie di problemi nel codice puramente per associazione. Dove ho cambiato / rielaborato / refactored qualcosa e risolto altri bug eccezionali. Quindi, anche se non so cosa li abbia originariamente provocati, ho trovato un codice dannoso e "risolto", cosa che ha risolto anche quei bug. Copro cambiamenti come questo con test unitari e di integrazione per garantire l'integrità dei requisiti aziendali e tecnici della funzione.

O è comune tra gli sviluppatori a volte far funzionare il programma senza conoscere veramente i dettagli sul perché la correzione ha funzionato?

Ci sono almeno tre grossi problemi con questo:

1. Porta a una mentalità di magia nera in cui ti arrendi all'idea di poter capire il codice e invece inizi a spostare le parti in giro sperando che i problemi scompaiano. Questo è l'equivalente programmatico di spingere il cibo nel piatto, sperando di far sembrare la tua cena sufficientemente mangiata da non farti mangiare più verdura dai tuoi genitori.

2. Non puoi sapere che il bug è effettivamente corretto o semplicemente mascherato dalla tua modifica a meno che tu non capisca a) quale fosse il problema eb) come la tua modifica risolve il problema.

3. Probabilmente il bug non è stato risolto e ti morderà di nuovo nel prossimo futuro.

Vedo due scenari: hai lavorato su qualcos'altro e il bug ha smesso di accadere, fintanto che qualcos'altro non ha rotto qualcos'altro, devi praticamente lasciarlo entrare - hai fatto ciò che era necessario / desiderato e aveva un effetto collaterale positivo imprevisto e inspiegabile.

L'altro è che stai lavorando su questo bug e una modifica casuale ha fatto funzionare le cose, questo è inaccettabile. Se non hai idea di cosa stia facendo il vecchio codice, probabilmente non hai idea di cosa stia facendo il nuovo codice.

Non riesco davvero a pensare a una buona ragione per controllare il secondo caso: se si tratta di un bug critico, è fondamentale farlo correttamente. Se si tratta di un bug non critico, almeno puoi essere sicuro di non introdurre un bug critico con la tua "correzione".

O è comune tra gli sviluppatori a volte far funzionare il programma senza conoscere veramente i dettagli sul perché la correzione ha funzionato?

Penso che sia molto comune in questi giorni. Questo è dovuto a Google e StackOverflow. Hai un problema con il tuo codice, basta cercarlo su Google, trovare una soluzione, risolto, passare al problema successivo.