Tips on Code Refactoring, From a Former Addict

As many of our developer readers know, refactoring is the process of rewriting existing code. Most developers know about it, and most like it. Why? Ask any developer what he thinks of the code he wrote a few days or weeks ago. Almost all of them will reply something like:

I'm telling you; developers love to refactor.

Usually, you refactor code to make it more readable, more maintainable. For instance, you could use new libraries or new concepts you've discovered since you wrote the first draft of the code. So what's the problem, you ask? The thing with refactoring is that it can quickly become and endless loop, hindering actual progress.

When I started my career as a developer, I think I had a serious refactoring addiction preventing me from actually shipping things to production. One very important thing you learn as you progress as a developer is to control your refactoring addiction. We almost all have the same itchy feeling about code we wrote a few months back, but sometimes you must get over it and do something more valuable for your product or project.

So today I'm going to tell you when I think you should refactor, and when you should not.

Good reasons to refactor

1. Avoiding technical debt

As your production grows, you might start to experience problems with the application architecture. Some of the technologies you decided to use in the past might become outdated. In this case, refactoring is part of the solution, and you need to do it. You might need to review the global architecture, or simply refactor the parts causing the issues. Either way, you will need to dive in the code and work your refactoring magic.

2. Learning a new code base

Recently, we hired a new intern developer, Francis Tremblay, at Snipcart.

The first feature I asked him to develop was related to shipping carriers integration. He started by looking at some code we did not work on in the last months or so. He told me: "I'd like to do some refactoring to make it easier to integrate new options." At first, I refused and told him to focus on the feature itself. Refactor would come later.

After a good night of sleep, though, I thought to myself: "Maybe he should do it. Refactoring the code would make him go through every class related to this part of our application. He'd learn much more by doing some refactoring than just filling in the blanks required to implement the feature." I told him to go ahead with the refactoring. I knew it would probably take him at least three to four times longer to deliver the feature, but in the end he did truly understand how shipping carriers work within Snipcart.

Don't forget, though: since refactoring can introduce bugs, it's important to do frequent code reviews while it's in progress. Having a solid test suite really helps avoiding that, but a review is still a very good idea: not only to find out possible issues, but also to make sure the code style is respected.

Long story short: I believe a good moment to do some refactoring is when you dive into a code base you're not familiar with. It'll definitely help you understand how things are wired together in there.

3. Integrating new, useful technology

When the team is whining about a specific technology used in the project, you must do something. Here's an issue of the sort we recently went through: we had been using RequireJS to bundle our client side applications. When we started Snipcart, it was almost the only option available to work on a large scale JavaScript application. But today, we have many other cleaner, easier options to work with. So one morning, after one too many developer complaint, we decided that we needed to solve this issue. We got rid of RequireJS. We decided to refactor and go with Webpack. Refactoring might be well worth it when it comes to integrating new and useful technology to your project.

Bad reasons to refactor

Making the code look prettier

As I stated at the beginning of this post, nearly every good developer hates the code he wrote when he looks back at it after a few days or weeks. But this in itself is simply not a good reason to refactor. You need to have a purpose that will bring actual value to the application. If the code works fine, you should not refactor it just for the sake of refactoring. Avoid at all costs the refactoring endless loop.

As a rule of thumb, you should only refactor code that is related to a feature you are currently working on.

Integrating new, useless technology

Now that's another prime example of when you should avoid refactoring: the moment you find a new technology that you think could replace something you already have. I know I've just told you refactoring to integrate a new technology can be a good idea. But the whole process must bring real value to your whole project. A new technology strong of 500 stars on its first day on GitHub is alluring indeed. But if it doesn't bring real value to the table, then it's not a good enough reason to refactor. Keep the library in your favorites or something; it might come in handy later on. Just don't refactor your working code simply to test it.

A quick word on refactoring at Snipcart

Today, refactoring is not as easy as it was on day one. Our backend architecture and our frontend app have both evolved heaps. Growing SaaS will surely face this challenge too. We are getting more and more customers, and the application is constantly receiving requests. So we really need to think through all the consequences a refactoring could have on our API and our client-side applications.

But still, we do frequent code reviews and try our best to stay up to date. And after all, working on new features and releasing new updates will be way healthier for our startup than refactoring the same old features.

I'd be more than interested in hearing your own thoughts on refactoring, whether you agree with mine or not. So if you have questions, comments or feedback, simply hit the section below. And if you enjoyed the post, please, take a second to share it on Twitter.