DEV Community

Cover image for You have received a horrible code at work, what will you do?
Juneau Lim
Juneau Lim

Posted on

You have received a horrible code at work, what will you do?

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)

engineercoding profile image
Wesley Ameling

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.

voidjuneau profile image
Juneau Lim

So there are even more cases then I originally thought. Never make an assumption is also a good lesson. Thanks you for that.

bradtaniguchi profile image

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.

  • I'd write some test-cases if possible, to verify the current existing behavior of the code. If it isn't possible or easy to test, I'd try to refactor it so I could test it. If its still hard to test, it might be too far gone.
  • I'd do some no-risk refactoring, clean up comments, format, etc.
  • I'd be damn well sure I understand what the code is doing, with or without tests.

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.

voidjuneau profile image
Juneau Lim

I feel sorry for putting you in an undesirable position. My apology for that, and thanks for your insight.

voidjuneau profile image
Juneau Lim • Edited

What a helpful mentor you are. I hope to meet someone like you when I start working. Thanks for your answer.