DEV Community

Cover image for Debug or Refactor? The Coding Dilemma!
dev.to staff for The DEV Team

Posted on

Debug or Refactor? The Coding Dilemma!

Would you rather spend an entire day debugging a complex code issue or refractor an entire codebase from scratch. It's a tough call! Share your preference and the reasons behind your choice.

Follow the DEVteam for more discussions and online camaraderie!

Image by pch.vector on Freepik

Top comments (15)

Collapse
 
fyodorio profile image
Fyodor

Debugging of course. Refactoring is not scalable. And you need to know your codebase and its flaws anyway, so if there's an issue, you need to dig and find it and not burry it under some other piles of code always risking to face it again. And don't forget to add a test after fixing, that will be a chef's touch.

Collapse
 
villelmo profile image
William Torrez • Edited

What mean scalable? Can i refactor a program in C?

Collapse
 
fyodorio profile image
Fyodor

Means it’s easy to refactor a pet project but if it’s a multi-app monorepo with intertwined network of dependencies you’ll question not only your choice of profession but life itself 😅

Thread Thread
 
villelmo profile image
William Torrez

😑

Collapse
 
manchicken profile image
Mike Stemle

Refactoring isn’t something you do from scratch, I think you mean rewriting.

As a general rule, I hate rewrites. They’re expensive, they trade known issues for unknown issues, and they tend to be unnecessary and a matter of personal preference.

I’m want to fix the wheel, not build the perfect and most round wheel that the world has ever seen by reinvention.

Collapse
 
wizdomtek profile image
Christopher Glikpo ⭐

I understand that choosing between debugging and refactoring can be a challenging decision. Both approaches have their merits, and the best course of action depends on the specific situation. Here are some factors to consider when deciding between debugging and refactoring:

  1. Severity of the issue: If the problem is causing critical failures or affecting the user experience significantly, it's essential to prioritize debugging and fixing the issue as soon as possible. On the other hand, if the issue is minor or doesn't impact the functionality, you might consider refactoring to improve the code quality.

  2. Code quality: If the code is difficult to understand, maintain, or extend, refactoring might be the better option. Refactoring can help improve code readability, reduce complexity, and make it easier to debug and maintain in the future.

  3. Time constraints: Debugging is often faster than refactoring, especially for small issues. If you're working under tight deadlines, it might be more practical to debug the issue and address the root cause later through refactoring.

  4. Team expertise: If your team is familiar with the codebase and has the necessary skills to refactor the code effectively, it might be worth investing the time in refactoring. However, if the team lacks the expertise or is new to the codebase, debugging might be a safer and more efficient approach.

  5. Long-term benefits: Refactoring can lead to long-term benefits, such as easier maintenance, better performance, and reduced technical debt. If the codebase is expected to evolve and grow over time, investing in refactoring might be a wise decision.

In summary, the decision between debugging and refactoring depends on the specific context and factors such as the severity of the issue, code quality, time constraints, team expertise, and long-term benefits. As a software engineer, it's essential to weigh these factors and make an informed decision that best suits the project's needs.0

Collapse
 
cyborglaksh profile image
Lakshgupta

Debugging is better approach as I am the developer I have pinch of logics where the code might go wrong.
Certainly prepare test cases against that and deliver the curated code which reduces redundancy and improves scalability.

Collapse
 
klvenky profile image
Venkatesh KL

I would go at this with how complex the issue is & how the codebase is. If the issue that occurred is something that doesn't happen that often(may be once in a quarter) & requires less than a day(assume 4 focused hours), I'd be okay to debug it. If it doesn't, then let's see what we can do the best.
Are there unit tests covering all use cases & give great confidence?

  • Yes - go for a refactor.
  • No - Calculate the effort needed to write a good test suite vs excellent manual testing(consider testing the feature 10 times if it's manual QA). If the effort is worth it, then go for refactor. Otherwise, look for better alternatives.
Collapse
 
ulisesserranop profile image
Ulises Serrano

I think that is depending on the problem to solve and the context. Complexity of the code and understand the business rules for example. if you can fix it is because you are an expert in this three options: in the business, in the language or both. I personally prefer debugging for the option one or two because is faster. The third option is only if the code is a disaster, complex and very old and exists one thing more modern to fix it easier.

Collapse
 
mxglt profile image
Maxime Guilbert

Debugging for sure (as it may involve some refactoring to fix the bug, improve the solution or make it easier for next researches)

Collapse
 
vulcanwm profile image
Medea

Debugging definitely.

Collapse
 
vegas73509 profile image
FuadVegas

Interesting discussion

Collapse
 
villelmo profile image
William Torrez

What is refactor?

Collapse
 
vsaulis profile image
Vladas Saulis • Edited

These are from very different domains. Like oranges vs apples. Debug is about making software to work correctly. Refactoring is about making software better.

Collapse
 
mauricebrg profile image
Maurice Borgmeier

If you don't understand the issue (i.e., debug it), how can you know that you solve it by refactoring everything?