Owning Continuous Refactoring As Part of Your Process

It’s safe to say that we, as developers, find refactoring to not only be a crucial part of our process, but one of the main ways we learn and improve in our everyday work.

However, supporting continuous refactoring in a consultancy, where clients and deadlines are a part of our livelihood, can be tough to manage because:

• It takes some extra time (at first)
• It can break features that are currently working
• It provides little to no tangible benefit for the client in the near term
• It can fall by wayside under the heavy load of feature requests for a client

Here are a few reasons you should make time for refactoring as you go. Don’t think of it as something extra you need to sell your clients on. Own it as part of your development process.

If you don’t do it now, you won’t ever do it.

The longer you go without refactoring something you’re meaning to, the larger and more daunting the refactoring process gets. As the codebase grows, the feature that needs refactoring will be touching more parts of the application, adding to the number of things that will break once you finally decide to refactor. Often, the code will get too cluttered for you to realistically have the time to go back and untangle the mess you previously left behind. By putting off refactoring, you’ll continue to inherit more and more ‘technical debt.’ As it piles up, it becomes less likely that you’ll have the time to repay it.

It’s like going to the dentist: if you skip your cleanings, you’re more likely to have cavities when you finally do decide to go.

You’ll become afraid of change.

In an agile development process, changes are constantly being made to an application. Cluttered, non-DRY code is not at all conducive to frequent iterations. If you leave messy code behind in an effort to get something shipped faster, the changes after that will be slower, more frustrating and prone to errors. This makes the app and those working on it more resistant to change, further slowing down future versions of the product. Going back to the dentist analogy, no one looks forward to going in for a checkup knowing that the dentist might discover some cavities.

If you want the code to evolve with the design of the app, refactoring as you go gives you a leg up; making you ready to take on changes as they become necessary.

It impedes your teammates

Often the code that needs to be refactored is code that is unclear, not object-oriented, and less transferrable to other developers. At least for us here at LaunchPad, it’s rare to only have one set of eyes on the code, so clarity is essential. If you’re not refactoring to keep the code clear in its purpose, you’re going to make it much more difficult for the dev next to you to do their job.

When should you refactor?

A couple of my teammates and I made what we thought are some good telltale signs for knowing when it’s worth taking the time to make things right.

You should refactor…

• when you find yourself copying/pasting or you see duplication.
• if there are nested conditionals.
• when another dev has more questions than normal about the functionality of some code you wrote.
• if you need to write comments in the code for the other devs (or yourself!).
• if you’re conditionally specifying environment type.

Obviously, a lot of things could be added to this list, but it’s a good general guideline.

By continuously refactoring, your code will stay clear, object-oriented, and rooted in reality. This makes your code more open to change, keeping it ‘healthy’ (less bugs, passing tests), keeping your teammates happy, and saving you time in the long run. By putting in the time to refactor, you’re ultimately providing a better and more sustainable process to your clients.

×

Subscribe to Our Newsletter

If you made it this far, you should sign up for our monthly newsletter. Get our latest articles and insights delivered each month.

First Name*

Last Name*

Email*