When Do You Know If It Is Time To Refactor

Kurt Cunningham
May 20, 2017 · 6 min read

We as developers and designers write a lot of code. Some of it is good and sticks around from project to project. While other pieces are hacks or quick implementations meant to solve an immediate need. These poorly constructed snippets shouldn’t follow us from project to project. But in reality, they often do.

How do we solve this problem? How do we know if it’s time to refactor and fix these hacks / quick implementations? When is it worth it to invest a few extra hours or days to create a better component, module, stylesheet, script, etc.?

Time constraints, budget issues and general laziness aside, team members at Made By Munsters ask themselves three questions when considering whether or not they should refactor a portion of their code. If we have any hesitations answering the questions below we know it’s time to invest in ourselves and our products.

Questions we consider:

  1. Is my code DRY, enough?
  2. Does my code align to modern web standards?
  3. Can I learn a new method or technique?

01. Don’t Repeat Yourself

The first qustion we consider is whether or not our code is DRY. This common development term stands for Don’t Repeat Yourself. Did you copy and paste any aspects of our code from one file to another? Could we create a simple loop or component that would allow us to achieve the same outcome, but create fewer lines of code?

Consider these additional questions when trying to answer whether or not your code is DRY. An example we could study is the creation of buttons in Sass. We use buttons on marketing sites, in web interfaces, and just about everywhere else. It’s easy to let these elements get out of control. Take these button selectors for instance:

In this example, we can see that we merely duplicated our buttons by copying and pasting. The only difference between the two button selectors above are the background colors. This violates the DRY principle. We could easily re-write these styles to be more DRY.

One way we could refactor this component might be to create a common button selector and then specific button selectors for the button types.

For example:

As you can see from this example, we abstracted the common elements from each button type and added them to a selector each button object can leverage. Additionally, we created button types or modifiers that we can add to a button object to provide the correct value.

Refactoring this component makes sense in this case because it allows us to reduce the amount of code in our project and allows us to update one selector vs many when a change to the core button structure is required.

02. Align to modern web standards

Next, we examine best practices and whether web standards have changed. Since the web is changing every day, it’s a pretty easy way of determining that we need to refactor. A few things we have considered lately is accessibility, CSS vendor prefixes and single-page appliction best practices.

Let’s take a look at our button example again. Notice anything that we could fix?

What about that transition property? According to caniuse.com, the CSS3 transition property is fully supported by modern web browsers. This means we can say goodbye to those nasty vendor prefixes.

Answering just that question helped us to remove three lines of code that were unnecessary.

03. Learn Something New

Lastly, one of the biggest influencers in our decision making process to refactor or not is if we can learn something new. As professionals, it’s our job to perform at the highest level and this means continuing to learn and providing added value to our own and client’s projects.

We could easily refactor our button example one more time to take advantage of a few features Sass provides us: Loops and maps. These features will allow us to keep our code DRY, align to modern web standards and learn something new in the process. Let’s take a look.

First we create a button map. If you haven’t created a map in Sass before it’s worth a look. Maps create key, value pairings that can be used to generate styles. They look and function very similar to javascript arrays. In the example above, we create a map called . This map stores a couple button types, and . Lastly, each button type contains two key, value pairs. These pairings will help us create our button styles.

Next, we replace our button types with an loop. This loop references the button type and key, value pairings - - we added to our buttons map. We pull out the styles and assign them to variables with the function and then simply reference those in our dynamically created selectors below.

Easy. Right?

While the previous method would have worked just fine, this new implementation allows us to extend our buttons without having to create any new selectors. We simply add a new button type to our buttons map and let the button loop take care of generating our newly created selector. We also learned something new about using a few Sass methods.

Could we take this further and learn something else? Sure. Maybe we need to explore ways to turn our button into a mixin that takes various options to control the and . This would allow us to create various button types in various sizes. But, we'll save that for another post.

When deciding whether to refactor your code consider a few things: Could your code be more DRY? Does it align to modern web standards? And can you learn something new by refactoring it? If you find yourself answering these questions positively, then it’s time to put your refactoring hat on and get to work.

Interested In Learning More?

I’ll be giving a talk on refactoring stylesheets at Front-end Camp in Chicago on June 3. Check out chicagocamps.org/ for more information. I look forward to seeing you there. Happy refactoring.

Originally published at madebymunsters.com.

Made by Munsters

Design-focused development agency

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store