3

Hey, as a fresher dev, what should be my approach to "fix some bug" ? Its been 2 months since i have joined a company , and i still often struggle when there comes a task of fixing bugs in old code.

Adding new stuff is rather easier for me, I just follow the way the practices and code patterns used in something similar, and usually my code is correct.

But when it comes to solving bugs, I usually try to follow the code in that class/module/function etc, come up with a million questions that no one would answer and eventually just remove all the old code and write my own.

Sometimes my seniors would be mad as I would touch the code "that is already working" , but that's the point, if that code was easy to understand and predictible, i wouldn't have rewrote it!

What's your take on fixing bugs?

Comments
  • 10
    That's called "shotgun debugging", sometimes also "voodoo debugging", and it's an antipattern.

    If you don't understand the existing code, you won't understand its intricacies either. Old code is quite often ugly to cover edge cases that you didn't think about yet. It's ugly, but battle-tested.

    The only situation where you can do a rewrite is if you understand exactly what the old code is doing, including edge cases. Otherwise, rewriting invites new bugs, that's why your senior devs are mad, and rightfully so.
  • 5
    See above. The challenge in fixing bugs is finding the exact breaking point, study it’s related code and finding a solution which replaces only the part that causes the problem.

    Coming up with questions is good, asking them is bad. Find the answer yourself by studying the code.
  • 6
    O the other hand, reading und understanding foreign code admittedly is a more difficult task than writing one's own code.

    Since you're a fresher, reading foreign code is a skill that you should work on. It's nothing magical, just experience. The more you do it, the better you'll get at it. We've all been there.

    If you work on that, you will come to the point where you see code and know that something is off just by looking at it, and you'll only have to analyse what exactly is wrong.
  • 3
    As the other say, if you do not understand the code and have questions you are not in a position to rewrite it.

    Generally rewriting is a well planned task involving an abundance of unit test or a detailed plan on how.

    I rarely rewrite code, I prefer to go through a number of refactoring steps each improving one aspect of the code and in between verifying that everything works.

    Sure I have rewritten things from time to time, for example when switching from net framework to net core and important api’s have changed or when the actual business process has changed enough to require it.

    But never ever just to fix a bug. First you find and fix the bug. Then if the code it in to bad shape you refactor it piece ny piece.
  • 0
    I place wide breakpoints and narrow them down until I find problems and fix them after that I forget about it.
  • 4
    If at this point you are struggling to understand existing code this much, perhaps the code is shit, but rewriting from scratch is very risky. On the other side it could be the existing code is not shit and you're just not skilled enough yet.

    I have worked with people with decades of experience that don't understand or recognise a basic pattern, and therefore say it's shit and want to scrap it.

    Anyway up you to decide what the truth is, even if it's a lack of skill it isn't something to feel bad about, it's quite normal, and something I did a lot as a junior (I didn't know enough to say something was bad and I didn't realise that either).

    My advice is to understand what exists before you rewrite. And never without first unit testing what's there. Replacing also has an emotional element as most devs won't be happy to see their work reviewed as so shit it needs scrapping by a junior. That is actually their fault, but be warned it can build up silently and backfire on you big time.
  • 0
    The best thing to do to start is to figure out the tooling surrounding the language. If you can't figure out how to run a debugger, how to run the code over and over again, how to view output, etc., you're going to waste endless hours on a wild goose chase.

    Then start doing code path analysis. Usually print statements work well for this. Find out where the code is executing, how/why it gets there, etc. This can help solve most LOGIC bugs.

    Memory leaks and the like usually require profiling tools. They differ based on your language.

    Segfaults in particular can mean one of two things - if the codebase is in a native language, use valgrind. If it's in a VM/interpreter, find out the line of code that causes the segfault. It's usually a bug in th VM that needs to be filled, and you should find a workaround "incantation" and label it with a big ol' comment.
  • 0
    Beyond that, there are 100 different types of bugs across all the different technologies and stuff. It's hard to really give concrete advice without that information.
  • 5
    1. Get repro steps
    2. Create n tests to represent the issue
    3. Make the tests pass
    4. Get a beer
  • 1
    @SortOfTested do not underestimate the 4:th step :)
  • 0
    Haha, after step 4 comes 5. Repeat The cycle
  • 1
    Thankyou for your comments everyone. I guess i agree that i shouldn't be re writing the code I don't understand.

    But the thing is , the libraries and the code written is usually the one that i have used before and i used in a manner where books or docs said its a "best practice" . Most tof the times i remember the advantages of using those practices , but not the harm that would come if not used in that manner.

    So when i see a code that isn't written in a manner it is supposed to be, my first suspect is the bad format of code, and i try to fix that as a part of my bug solving process.

    Just like @Voxera , i would refactor code into many small commits ,moving code into functions and testing it, until i reach a particular deadzone code that is 1) non-understandable to me 2) highly coupled and with code mixing and 3) probably the cause of bug. At this point i will either leave that code as it is and treat it as a black box or make my senior more mad by going into that function too.
  • 1
    But even before reaching at that stage, i will end up refactoring 90% of screen and that would still make the seniors mad
    Ofcourse @craig939393 is also correct in doubting me and yes it is more of a possibility that am too dumb to understand the working and therefore prematurely calling the code as shit.

    I am in a kind of catch-22 situation. If i declare the code as shit, i will have to prove myself and come up with a challenging better architecture that handles all the bugs. And that too is gonna make my senior look bad in front of tech lead and he will be mad at me.

    If i don't, then am stuck with a risky code dangling on thin threads, which whenever fucks , is going to get me the blame coz i was the last person to work and add feature in it :/

    Sorry this went from general discussion to a very specific , current office scenario.
  • 0
    @yowhatthefuck Maybe you could first prove yourself to your seniors and only do actual bugfixes without introducing a lot of other changes?

    This way, they would be able to easily check the diffs, and see that you know what you're doing.

    Once you have earned that trust, you can suggest improving the code quality without them suspecting that you might change it into clean, but functionally buggy code.
  • 1
    @yowhatthefuck actually you can be very clever and just not have knowledge of design patterns and domain modelling yet.

    The problem is that writing good code requires a lot knowledge, that's why it's so hard and why different people with different knowledge gaps have wildly different ideas of good code and good design.

    That's why I always recommend books by leaders in the field. Their approaches are tried and true and can get people on the same page with their guidance.

    You say you have to refactor a lot to make the code understandable before fixing a bug. So then my unsolicited advice:

    Read Robert Martin's Clean code. Apply it for a couple weeks at least.

    Read about unit testing and unit testing patterns / strategies. It is worth it, it all comes together.

    Read about gang of four design patterns.

    Then look at the code and assess why you have to rewrite large amounts of library usage code. Perhaps it's because the code using the library is not well designed.

    1/2
  • 1
    @craig939393

    What I mean by that is that I can't imagine my own code exposing so much library details that and so many bleeding concerns that fixing a specific problem requires a huge refactor. This sounds like code smell from your seniors.

    At that point you should be equipped to have an idea of decent OOP code, applied at a small component level.

    With the knowledge of separation of concerns, encapsulation, abstraction, the SOLID principles and unit testing you can access why you have to rewrite an entire screen or file to fix a bug.

    If the problem is not your end, write unit tests to ensure you don't break anything existing, and start refactoring to the above principles.

    If you make a genuine effort to do that and your seniors don't listen or they don't understand that stuff, it's a dick thing to say but I would disregard almost everything they say. After learning the above only.

    2/2
  • 1
    @craig939393 P.S you might not apply it all correctly which is normal. Applying these concepts even 50% correct is better than not because change when you have tried can be difficult, but not extremely. It might be easy which is actually the point of the ideas I have.

    Changing code with none of this stuff applied is very risky, often very large, and very difficult.
  • 2
    @yowhatthefuck Its still a problem if you refactor first as refactoring code with a known bug can make it even harder to find the bug as you might refactor the bug into code that looks better but is further from the logic that was intended.

    Sometimes you can use refactoring as part of bug hunting but once you find the real culprit you go back to the original code to do the real fix.

    A bug fix should change little code as possible while solving the problem.

    If the code is hard to understand, well you say you can rewrite it, that means you claim to understand the problem.

    Comparing your code to the existing should not be to difficult and if it still is this suggests that you still do not fully comprehend what the existing code does.

    It can be that they are using som undocumented feature that is necessary or that they are doing things for performance reasons.

    It can also be that the dev is bad, but then its even ore important to really understand it do that you can defend your code to every one else.

    Now, I do not know everything about your situation. You might have morons as bosses that put you in an impossible situation between their expectations and old second rate devs in which case things get a lot more exciting in all the wrong ways.

    But I would really do more to understand the existing code before rewriting.

    If they are bad devs and you are better you should be able to decipher their mess.

    If you cannot, you might still be better than them, but not better enough yet, and a good way forward is to understand their code.

    If you can pinpoint exactly what they did wrong and why it is wrong you stand a lot better chance of earning their respect and later get away with rewriting.

    No guarantee of cause, if they are dickheads on top of bad developer its probably a lost cause and your best bet is to prove your self to the boss until you can disregard the old guard.
Add Comment