This was an actual interview (which I failed) question I was asked.
The answer I said (Mostly focused on styling/structure)
Bad code might have its own purpose.
Even if the code looks messy, there might be the reason that it has been written that way. Or, at least, people are already used to it. Changing an existing schema will cause confusion and harm to productivity.
It could be waste of time to fix it.
Even though There is no reason to keep the code, fixing it might be a waste of your time, especially if when the code is not used constantly. You need to determine first if it is necessary to fix it.
The answer I have found online (focused on debugging)
Clarifying comments
figure out what the code does and try to clear it out by stating with comments for yourself and the next person rather than touch actual code to risk breaking
No risk fix
add a special case. It would be safer and faster, but the real issue wouldn't be fixed.
Delete and Rewrite
Just threw away everything and do again from scratch.
Whoever wrote this is an idiot.
It would be clean and simple.
What do you think would be the best option? Do you have another good idea? Please share your opinion.
Top comments (5)
Honestly it depends on the context. If you received it as a code review, then it is your job to talk with the author and ask why it was done this way. If it was a high priority fix for prod and tests prove it works, sure deploy and refactor afterwards. If it is a random ticket, and no real reason is supplied, educate the author how to refactor it to something proper and assign it back.
In the actual interview I would ask for the context, because I think this question deserves a context aware response. If you get the question why do you need the context, then explain different contexts deserve different actions.
So there are even more cases then I originally thought. Never make an assumption is also a good lesson. Thanks you for that.
Assuming a best-case scenario where I have time to commit to refactoring, I actually understand what the code is doing, and there is at least some supporting code like tests, comments, docs, etc.
In the worst case, where I can't write tests, its extremely complicated and extremely critical, I'd try to do as little as possible to it to prevent any breakage down the line. I'd also keep the code in mind as a candidate as a refactor/re-write.
I believe if you can write tests for code, you can refactor it much easier, without worry. If you can't write tests for dirty/ugly code, then changing it is risky, and since not all code can be tested easily it might not be worth the risk and work, especially if the code works.
I feel sorry for putting you in an undesirable position. My apology for that, and thanks for your insight.
What a helpful mentor you are. I hope to meet someone like you when I start working. Thanks for your answer.