Approccio al bug fixing

Nella mia testa ciò solleva campanelli d'allarme.

Certo, non sono un programmatore di database. Il mio lavoro non è così cruciale per la sicurezza, ad esempio. Ma quando dici

But sometimes what I do is fed up of doing some research (cant find suitable information on the internet) I just change the logic which takes me much less time as compared to the other.

Ho la sensazione che tu sappia a te stesso che l'approccio che stai prendendo è molto probabilmente non quello che dovresti prendere.

A me sembra che tu stia trattando i sintomi piuttosto che il problema di fondo. E non posso dire di non averlo mai fatto. Ma l'esperienza mi dice che, anche se potrebbe non succedere mai, di solito tornerà a morderti in posti dove non vuoi essere morso.

Direi che la tua ultima frase è corretta. Prenditi il tempo per trovare e correggere l'errore originale. Non puoi essere sicuro di aver risolto il problema se non hai capito quale fosse il problema in primo luogo.

Qualsiasi soluzione alternativa potrebbe esteticamente risolvere il tuo problema, ma potrebbe anche introdurre effetti collaterali a cui non avevi pensato, oltre a lasciare il tuo sistema esposto al problema originale.

"Risolvere" un bug smanettando le cose e cambiandole in modo che il problema non compreso scompaia è una strategia terribile.

È cattivo perché:

a) non hai imparato nulla su un potenziale punto debole del tuo sistema o del software / framework / risorse che stai utilizzando

b) scambiando le cose intorno a te potresti solo introdurre nuovi problemi

Se hai una scadenza molto serrata e il tuo approccio è la tua migliore speranza nel tempo a disposizione, allora puoi tirarti fuori da un punto critico (forse). Ma lo farei solo come ultima possibilità, e poi tornare indietro e scoprire qual è il problema dopo la scadenza.

Questo in realtà mi ricorda un ex collega che non capiva perfettamente la logica booleana (sì, davvero). Girava con le sue espressioni booleane (nidificazione di ands e ors) finché qualcosa non funzionava. Anche se riesci a ottenere qualcosa lavorando facendo queste cose, non hai capito il problema, e ti stai anche affidando in certa misura alla fortuna.

Se puoi semplicemente buttare via la parte del codice che contiene il bug, e il prodotto software è ancora funzionante e conforme ai requisiti originali, allora non dovresti aver scritto questa parte del codice nel primo posto.

Quindi sì, se puoi risolvere un bug rimuovendo il codice che non ti serve, questo è un buon approccio. Potresti ancora chiederti perché hai scritto il codice che non ti serve.

In effetti, questo non sarebbe il modo corretto per farlo. A mio avviso, ciò aumenterà la possibilità di creare nuovi bug o la possibilità che qualcuno trovi di nuovo lo stesso bug.

I bug dovrebbero essere corretti, non risolti.

Ovviamente non sono sicuro di cosa lo hai sostituito. Se hai sostituito una query errata con una corretta, potresti chiamarla una correzione. Se tu ne scrivessi uno completamente diverso sarebbe un aggiramento se me lo chiedessi.

Meglio provare e correggere il bug per assicurarti che non mostri di nuovo la testa!

Il tuo approccio è prezioso finché puoi giustificare il motivo per cui funziona. Sembra che tu sia abbastanza insicuro da chiedere qui.

Hai eseguito una parte della giustificazione: controlla che la query buggy (test fallito) non sia più bacata (passaggi di test).

L'altra parte della giustificazione è controllare che nessun'altra query (ogni test) diventi bacata (tutti i test passano).

Solo così puoi fidarti del tuo approccio.

Se vuoi dire che invece di analizzare una pila di WTF, la scarti, la riscrivi e la collaudi, allora il tuo approccio ha senso per me. Il codice danneggiato non ha valore.

Ho spesso risposto alla domanda "Cosa c'è di sbagliato in questo codice?" con "A chi importa? Ecco una soluzione."

La cosa buona del tuo approccio è che puoi concentrarti su cose che richiedono attenzione immediata. Il passaggio laterale per indagare su cosa inizialmente è andato storto potrebbe richiedere molto tempo e portare a termine il bugfix ben oltre le scadenze.

Brutta cosa è che il problema collaterale potenzialmente importante rimane irrisolto. Dal momento che non sai cosa è veramente andato storto, c'è una possibilità che questo "sbagliato" ti morda dolorosamente nel bel mezzo di correzioni di bug ancora più importanti e urgenti.

Per gestire "collisioni" del genere, tracker dei problemi sembra essere uno strumento creato in paradiso. In casi come te descrivi, semplicemente "forchetta" un nuovo ticket dedicato per gestire il problema secondario che ho scoperto. Quel biglietto dedicato rimane lì fino a quando non ho finito con la correzione corrente, dopodiché ritorno al nuovo ticket e lo risolvo.

Issue 1234: investigate root cause of Issue 1233 - find out what went wrong with <old logic>

• ^{Il trucco con "biforcarsi un biglietto" è un'applicazione pratica di decomposizione principi. La decomposizione è nota come una potente strategia nella progettazione del software; nella mia esperienza ha dimostrato di essere abbastanza utile anche nel tracciamento dei bug.}

Quello che di solito cerco di fare quando correggo un bug è:

• Conferma che il bug esiste. Preferibilmente "documenterò" il bug scrivendo un caso di test che fallisce a causa del bug. Questo ha anche il vantaggio di sapere che questo test case farà ora parte della suite di test del prodotto, quindi se l'errore si ripresenta questo sarà confermato dai test di regressione (supponendo che si eseguano test di regressione ovviamente!).
• Fammi familiarità con il codice che causa il problema. Se non sono ancora sicuro se interromperò qualcos'altro con la mia correzione di bug (oh ironia) scriverò più casi di test per documentare il comportamento di il codice indicato. Questo non solo mi avvantaggia, ma anche altri che passeranno attraverso lo stesso codice alla fine.
• Correggi il bug.
• Assicurati che tutti i test case che riguardano la mia correzione di bug siano passati.

Fondamentalmente cerco di mantenere una rete di sicurezza per tutte le mie correzioni di bug solo per essere sicuro di non causare altri bug. Capisco anche che a volte sarà più facile cambiare il codice e farlo, ma allo stesso tempo può valere la pena dell'investimento iniziale, dal momento che non solo tu, ma anche altri che si occupano dello stesso codice, beneficiare di una copertura di prova maggiore.