I have been working on a database project, and I recently received a bug report for the remote execution of some queries.
Usually, you try to find out the actual cause for the bug to occur and then fix it.
But sometimes what I do when I'm fed up of doing some research (and can't find suitable information on the internet) is just change the logic, which takes me much less time compared to the other option.
Is this approach correct, or should I try to fix the original bug involving more R&D?
In my head this raises alarmbells.
Granted, I am not a database programmer. My work is not nearly as security critical for example. But when you say
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.
I get the feeling that you know yourself that the approach you're taking is most likely not the one you should be taking.
To me it seems you're treating symptoms rather than the underlying problem. And I can't say I have never done so. But experience tells me that, although it might never happen, this will usually come back to bite you in places you don't want to be bitten.
I would say that your last sentence is correct. Take the time to find and fix the original bug. You can't be sure you've fixed the issue if you haven't figured out what the issue was in the first place.
Any workaround might cosmetically solve your problem, but could as well introduce side-effects you hadn't thought of, besides possibly still leaving your system exposed to the original problem.
"Fixing" a bug by fiddling with things and changing them so that the non-understood problem goes away is a terrible strategy.
It is bad because:
a) you've learned nothing about a potential weakness in your system or the software/frameworks/resources you're using
b) by swapping things around you might just introduce new issues
If you're on a really tight deadline and your approach is your best hope in the time available, then it can get you out of a tight spot (possibly). But I'd only do that as a last chance option, and then go back and find out what the problem is after the deadline.
This actually remind me of an ex-colleague who didn't quite understand boolean logic (yes, really). He'd jigger around with his boolean expressions (nesting ands and ors) until something worked. Even if you can get something working by doing such things, you've not understood the problem, and you're also relying to a certain degree on luck.
If you can just throw away the part of the code which contains the bug, and the software product is still functional and conform to the original requirements, then you shouldn't have written this part of the code at all in the first place.
So yes, if you can solve a bug while removing the code that you don't need, this is a good approach. You may still ask yourself why you've written the code that you don't need.
Indeed, this would not be the correct way to go at this. In my opinion this will only raise the chance of creating new bugs or the chance of someone finding this same bug again.
Bugs should be fixed, not worked around.
Of course I'm not sure what you replaced it with. If you replaced a faulty query with a correct one you could call it a fix. If you wrote a completely different one it would be a work around if you ask me.
Better try and fix the bug to make sure it doesn't show it's head again!
Your approach is valuable as long as you can justify why it works. You seem to be unsure enough to ask here.
You performed one part of the justification: check that the buggy query (failing test) is no longer buggy (test passes).
The other part of the justification is to check that no other query (every test) becomes buggy (all tests pass).
Only then you can trust your approach.
If you mean that instead of analyzing a pile of WTF, you discard it, rewrite, and test, then your approach makes sense to me. Broken code has no value.
I have often answered the question "What's wrong with this code?" with "Who cares? Here is a solution."
Good thing about your approach is that one can focus on things requiring immediate attention. Side-stepping to investigate what initially went wrong might take a lot of time and push completion of the bugfix far beyond deadlines.
Bad thing is that potentially important side issue remains unresolved. Since you don't know what really went wrong, there is a chance that this "wrong" bites you painfully in the middle of even more important and urgent bug fix.
To handle "collisions" like that, issue tracker appears to be a tool made in heaven. In cases like you describe, I simply "fork" a new dedicated ticket to handle side issue I discovered. That dedicated ticket hangs in there until I am done with current fix - after that, I return to new ticket and sort it out.
Issue 1234: investigate root cause of Issue 1233 - find out what went wrong with <old logic>
What I usually try to do when I'm fixing a bug is:
Basically I try to keep a safety net for all my bug fixes just to make sure that I don't cause additional bugs. I also understand that it sometimes will feel easier to just change the code and be done with it, but at the same time it can definitely be worth the initial time investment, since not only you, but also others who deal with the same code will benefit from having an increased test coverage.
