Quando eseguo il debug, a volte trovo che apporto alcune modifiche e non sono sicuro al 100% perché quelle modifiche correggano alcuni bug nel programma. È essenziale comprendere ogni singolo dettaglio sul perché si sono verificati alcuni bug e sul motivo per cui alcune modifiche hanno eliminato questi bug? Oppure è comune tra gli sviluppatori a volte far funzionare il programma senza conoscere davvero i dettagli sul perché la correzione ha funzionato?
Direi che è essenziale comprendere ogni singolo dettaglio sul perché alcuni bug si sono verificati e perché alcune modifiche hanno eliminato questi bug, e è anche comune tra gli sviluppatori a volte far funzionare il programma senza conoscendo davvero i dettagli sul perché la correzione ha funzionato!
L'arte di cambiare le cose fino a quando un bug scompare, senza capire cosa l'ha causato o perché il cambiamento lo ha risolto, viene spesso chiamato "programmazione voodoo" e non è un complimento. Non c'è davvero alcun modo per cui tu possa avere la certezza di avere riparato un bug, invece di correggerlo parzialmente per il caso specifico che stavi investigando, se non capisci cosa lo ha causato.
Nel peggiore dei casi, non hai fatto nulla, tranne spostare il bug: mi ricordo dal primo anno di informatica all'università, quando molti studenti stavano imparando C e puntatori per la prima volta, i bug del puntatore spesso smettevano di manifestarsi quando hanno cambiato le cose in modo casuale, perché i cambiamenti avrebbero riorganizzato le strutture dei dati in memoria abbastanza da far sì che il puntatore del bug calpestasse un diverso frammento di memoria. Ovviamente questo non ha aiutato affatto .
Ma detto questo, le realtà commerciali della programmazione sono spesso tali che soddisfare il cliente che un bug è stato risolto è più importante che soddisfarti. Non ti consiglierei mai di dichiarare qualcosa risolto se avevi nessuna idea che cosa l'avesse causato, ma se vedi che un codice era problematico e lo hai rielaborato, anche se non sei "al 100% certo "in che modo questo ha causato l'insorgenza del bug specifico, a volte devi solo passare al prossimo bug prima che il client grida troppo strong per i tuoi progressi lenti.
Se pensi che un cliente sia arrabbiato per aver impiegato troppo tempo a correggere un bug, immagina quanto saranno pazzi per un bug ricorrente che hai affermato essere stato corretto, o una correzione per una cosa che peggiora qualcos'altro. Se la tua soluzione è solo una soluzione o una soluzione, i clienti di solito lo accolgono, ma devi essere onesto su quello che è, e hai messo tutto il log di cui hai bisogno per sistemarlo per davvero.
Se sei abbastanza sicuro di averlo corretto, ma non sai perché la correzione funziona, chiedi a qualcuno. La maggior parte degli ingegneri che conosco ama per ottenere domande del genere a causa del mistero che c'è dietro.
Cambiare roba fino a quando il bug non è più c'è generalmente una cattiva pratica, ma sfortunatamente una realtà per alcune persone.
Sono dell'opinione strong 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 infranto qualcos'altro?
Generalmente, prima di correggere un problema / bug, dovresti eseguire una valutazione / analisi della causa sottostante per determinare perché il problema si sta verificando e se può essere replicato. Quindi dovresti leggere il codice e capire perché il codice sta causando l'errore. Una volta che hai capito bene, allora puoi iniziare a vedere come risolvere il problema e determinare altre aree che avranno impatto sul / sui tuo / i cambiamento / i. I test unitari possono davvero aiutare qui!
Ho visto un certo numero di modifiche al codice che le persone hanno fatto per risolvere un problema (che è grandioso), ma purtroppo ha introdotto altri problemi perché lo sviluppatore non era consapevole del pieno impatto di ciò che hanno cambiato. Molte di queste "correzioni" nascondono solo la causa alla base del problema originale e introducono complessità e altri bug.
Detto questo, ho risolto un numero di problemi nel codice esclusivamente per associazione. Dove ho cambiato / rielaborato / refactored qualcosa e ha corretto altri bug in sospeso. Quindi, anche se non so cosa li abbia originariamente originati, ho trovato il codice dodgy e "risolto" - cosa che è accaduta per correggere anche questi bug. Copro modifiche come questa con test di unità e integrazione per garantire l'integrità del business e i requisiti tecnici della funzione.
Or is it common among developers to sometimes get the program working without really knowing the details about why the fix worked?
Ci sono almeno tre grossi problemi con questo:
Porta a una mentalità della magia nera in cui rinunci all'idea di poter comprendere il codice e invece di iniziare a spostare le parti in giro sperando che i problemi vadano via. Questo è l'equivalente di programmazione di spingere il cibo in giro sul piatto, sperando di far sembrare la tua cena sufficientemente consumata che i tuoi genitori non ti faranno mangiare più delle tue verdure.
Non puoi sapere che il bug è effettivamente corretto o semplicemente mascherato dal tuo cambiamento a meno che tu non capisca a) qual è il problema, eb) come il tuo cambiamento risolve il problema.
Probabilmente il bug non è stato risolto e ti morderà ancora nel prossimo futuro.
Vedo due scenari: hai lavorato su qualcos'altro e il bug ha smesso di funzionare, purché qualcos'altro non abbia infranto qualcos'altro, devi praticamente lasciarlo andare - hai fatto ciò che era necessario / voluto e ha avuto un effetto collaterale positivo imprevisto e inspiegabile.
L'altro è che stai lavorando su questo bug e un cambiamento casuale ha reso le cose funzionanti, è 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, allora è fondamentale farlo bene. Se si tratta di un bug non critico, almeno puoi essere sicuro che non stai introducendo un bug critico con la tua "correzione".
Or is it common among developers to sometimes get the program working without really knowing the details about why the fix worked?
Penso che sia molto comune in questi giorni. Questo a causa di Google e StackOverflow. Hai un problema con il tuo codice, google, trova soluzione, risolto, passa al prossimo problema.