Tips on Code Refactoring, From a Former Addict

Tips on Code Refactoring, From a Former Addict

In this post, our lead engineer Charles, former refactoring addict, tells you when you should (and shouldn't) refactor your code.

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:

Crap, I'm still wondering why I did it this way. I'd do it differently if I could rewrite it today.

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.


There he is

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. I won't go into details about Webpack just yet; it'll be the subject of another post. In any case, 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.

visual studio code visual studio code

Bootstrap 5 Complete Course with Examples

Bootstrap 5 Tutorial - Bootstrap 5 Crash Course for Beginners

Nest.JS Tutorial for Beginners

Hello Vue 3: A First Look at Vue 3 and the Composition API

Building a simple Applications with Vue 3

Deno Crash Course: Explore Deno and Create a full REST API with Deno

How to Build a Real-time Chat App with Deno and WebSockets

Convert HTML to Markdown Online

HTML entity encoder decoder Online

COMO USAR e trabalhar com Code Review no Visual Studio Code

💲 Live CollabPlay: 💲 Hospedagem com Desconto Exclusivo: Não é todo programador que gosta de compartilh...

User Snippets (Code Shortcuts) in Visual Studio Code

#vscode Hello, my friends and fellow developers, this video is all about User Snippets. That means the Snippets (Code Shortcuts) that you can make for yourse...

Python в Visual Studio Code

We are pleased to announce that the July release of the Python extension is now available for Visual Studio Code. You can download the Python extension from the Marketplace, or install it directly from the extension gallery in Visual Studio Code. If you already have the Python extension installed, you can also get the latest update by restarting Visual Studio Code. You can read more about Python support in Visual Studio Code in the documentation .

C++ Development with Visual Studio Code

If you’re looking for a fast and lightweight open-source code editor, Visual Studio Code has you covered. Come for a deep dive into the features of Visual Studio Code which provide a rich, productive environment for C++ development.

The History of Visual Studio Code

We speak to the creator of Visual Studio Code about the early challenges to now becoming the most popular development environment in the world.