0

As someone who hasn't really gotten into large-scale corporate software development--I'm 17, I wanted to ask a question about programming practice.

If you encounter a bug in an application, and you apply attempts at fixes, before realising the actual fix to the bug; should you revert your original fixes, if the application still functions with these fixes; or, should you keep them and apply the actual fix?

Is keeping them more likely backfire later, as you may have broken something else, or are you more likely to have spotted other areas of a program that needed to be changed?

Improve this question
6
  • 7
    You don't exactly "attempt" fixes. You usually try to add automated tests that replicate the bug, then write code until those tests no longer fail. You can then try to replicate the bug manually in app to ensure it no longer happens. At this point, you should be confident you solved the issue, and if another one arise, there's no reason to remove code that fixed an actual issue (as you detected it in the tests).
    – Vincent Savard
    Commented May 3, 2017 at 16:18
  • Do people really write unit tests per bug?
    – Tobi
    Commented May 3, 2017 at 16:19
  • 5
    It doesn't have to be a unit test, and no, not everyone does it, but they should. I consider that writing the test ensures that I understand how the issue happens, and when I write it beforehand, I can be confident that the code I wrote fixes the issue.
    – Vincent Savard
    Commented May 3, 2017 at 16:28
  • @Tobi yeah, if you find a bug, write a test that fails and then fix it is good practice
    – Ewan
    Commented May 3, 2017 at 16:45
  • What are these "attempted fixes"? Are they changes to the program that don't improve it in any way? If so then why would you put them in the program? Source control makes it easy to throw away failed changes.
    – Criticizing Israel not allowed
    Commented May 4, 2017 at 3:01

4 Answers 4

Reset to default
4

Because you source code is in source control like git, you have quite fine control over the various versions of your software. So you have both options available to you.

What you do in practice depends on the bug. Lets say you have an e-commerce site and the bug is, when i buy two items it doesn't add the price of the second one.

You look at the code and you see a mistake in the basket object, it doesn't multiply by the quantity, so you add that in and it seems to fix the problem.

But then the next day you get another bug report, when you add socks it charges you for two pairs. you realise that the quantity of socks is 2 when you buy a single pair and your bug fix doesn't work for socks.

So, now you have a choice, change the code so that pairs have quantity 1 and leave your original fix in place. Or, replace the calculation code with something more complicated which checks for pairs.

Changing the quantity thing might have all sorts or repercussions. You don't want to mess with that even though it seems crazy to count pairs as 2 things.

Also, if you weren't the dev who put the 'multiply by quantity' bit in, well you dont really know if that it wrong or right either. Probably you just tack an ugly fix into the code, 'if item is a pair, divide quantity by 2 before multiplying'. It seems bad, but in many cases its the best thing to do.

With live apps you have to weigh the risk of breaking things vs the elegance of the solution. Often the quickest, smallest change is economically the correct thing to do.

This is why automated tests are so important. If you have confidence that you haven't broken anything then you are able to write better code. Because you can refactor more for the same level of risk.

Improve this answer
1
  • 2
    Automated tests for bugs are called regression tests; might want to note that. They catch when the bug is re-introduced (a regression).
    – Frank Hileman
    Commented May 3, 2017 at 18:14
3

Is keeping them more likely backfire later, as you may have broken something else, or are you more likely to have spotted other areas of a program that needed to be changed?

If the programmers know what they are doing, they hopefully know what the previous attempts do to the program.This should allow them to evaluate whether they are improvements or 'hacks', which in turn should allow them to decide whether to keep or remove.

Of course there could be 'neutral' changes, and in those cases I suspect the testing strategy will have a say on what happens; if the other changes will need extra work for no obvious immediate benefit then they are likely to go.

Improve this answer
0
0

Honestly, it really just is situational. Say you create a bug fix which addresses an issue, but something even bigger occurs. Maybe you'll find that the bug fix you already did can be expanded, being the best way to address the source of the problem. Maybe that fix will cause more errors.

Its just a matter of experience in the end (I learned the hard way). The more projects you work on and the more situations like this you run into, the more you will learn which choice to make.

Improve this answer
-2

You should never commit a change unless you are confident you have the correct fix. If you are not sure you have the correct fix, don't fix anything. It is always best to isolate your commits, changesets, what have you in your configuration management system, to only the necessary changes for the fix. Other "fixes" (other bugs) can be done in a separate commit.

If you find yourself having this problem, you should probably spend more time analyzing the problem, and less time running the code in the debugger.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.