How Should We Prepare to Refactor Our Code?
Photo by Mimi Thian on Unsplash

Programs are always changing as new requirements come in. Unless we replace it with something completely new, the code is always going to be worked on.

In this article, we’ll look at how to we prepare to refactor our code so that we can rework our code to make maintenance easier.

When Should We Refactor?

Refactoring is something that we may have to do when we have to change code so that we can meet new requirements.

If things can’t be merged together or anything that looks wrong, then we’ve to change them to make them right.

Duplication is something that we should eliminate in our code. Is anything violates the DRY principle, then clean those up.

Nonorthogonal code should also be changed so that they’re orthogonal. Having code that doesn’t break other parts when changing them is critical.

Any outdated code should also be updated. If there’s dead code, then remove them. Code that meets outdated requirements also has to be updated to meet new requirements.

If the performance requirements aren’t met anymore, then we have to move the functionality from one area of a system to another to improve performance.

Real-World Complications

We may not have time to refactor now. But if we don’t do it now, then we’re just compounding the problems with our code and we’ll run into problems later.

We got to explain this to stakeholders so that we’re given the time to refactor our code.

If we wait longer, the problems that arise from not refactoring will get worse.

Refactor Early, Refactor Often

Therefore, we should refactor whenever we need to do it.

Refactoring is all about redesign our existing code. Anything that the team designed can be redesigned in light of new facts, deeper understandings, changing requirements, and anything else that arises.

It’s something that needs to be undertaken slowly, deliberately and carefully.

We shouldn’t try to refactor and add functionality at the same time.

Good tests should be in place before refactoring so that we can make sure that our refactoring didn’t break anything.

Some IDEs can do simple refactoring for us automatically like cleaning up unused imports, so we may want to take advantage of that.

Also, we should take small, deliberate steps when we’re refactoring. For instance, we move one field from one class to another.

Then we test and do the next step.

Code That’s Easy to Test

Code that’s easy to test will make our lives a lot easier.

They need to be tested before they’re released to the public.

We can make our code easy to test by writing code that are easy to write unit test for.

A unit test will establish some kind of artificial environment for us to test our code in there.

It checks that our code returns the results that we expect by calling it with a given input.

Then we can assemble all of those unit tests together and run them as a suite.

Photo by Stefan Steinbauer on Unsplash

Testing Against Contract

We’ve to write test cases to make sure that a given unit honors its contract. It tells us whether the code meet the contact and whether the contract is what we think it means.

We want to test modules that deliver the functionality it promises by checking against a wide range of test cases and boundary conditions.

Therefore, to test any function comprehensively, we’ve to test them against a few cases.

We can pass in some invalid arguments and ensure that it’s rejected.

Also, we’ve to pass in some boundary value and ensure that the result is correct.

Then we pass in some valid arguments and ensures that the result is still correct.

However, most modules depend on other modules. This means that we have to do more work to write our tests.

Our tests would test the submodules that the current module depends on first, and then test the behavior of the module that we’re trying to test.

With comprehensive test coverage, we avoid lots of issues that we’ll miss if we don’t have enough tests.

Conclusion

We should write testable code so that we can run tests to make sure that we didn’t break anything when we’re refactoring.

Refactoring is important since requirements change so that we’ve to change our code to make sure that everything still works after we changed them.
['John Au-Yeung']
['Technology', 'Software Development', 'Productivity', 'Programming', 'Web Development']