This is a draft post from RedBeardLab an Engineering consulting company.

The best articles end up in our substack and get distributed over email to all our subscriber.

This article is to answer a Reddit post

I believe there is a wide misunderstanding of the word.

Refactoring is about changing code WITHOUT changing its behaviour.

<aside> 💡 You are NOT refactoring your code if you are adding a feature. Or fixing a bug.

</aside>

Refactoring COULD (and oftentimes SHOULD) be part of the active work of adding features or fixing defects.

Some developer think that refactoring is a failure in design or in coding. This is false.

Refactoring is healthy and it should happen as the codebase evolve and the business needs change.

Suppose you are working on a e-commerce system and you are handling taxes.

The company is focusing to serving a single market and it needs to charge 10% of sales tax on every purchase. A sensible design here would be hard coding the 10% in some module that computes the total cost for the final costumer.

Business keep growing and they decide to open up the shop to two markets, the second however has 20% VAT. Yes, the original design was not perfect but we can handle an extra if in the codebase. You push down the market that you are selling to the total cost module and add a condition to compute the right total cost. Then you add a few test cases for each market.

As the business keep expanding, management decide to open up orders worldwide. Now you need something more than a big switch case.

And NOW, you refactor the code.

Without adding any features you want your code to produce the exact same result of before in the original two cases. BUT with an extensible design.

You change the code, WITHOUT changing the tests.

You make sure that the code is still correct.

And here you have finished your REFACTORING step.