Four Ways to Refactor for Easier Development

Refactoring isn’t just about optimization or replacing some ugly code with something more elegant. It’s also a chance to keep things organized and consistent, which:

  • Helps new team members understand things better.
  • Helps everyone contribute faster because they don’t have to consider competing patterns or conventions.

These issues tend to be easier to spot and fix than a slow piece of code that needs to be optimized. So next time you find yourself wanting to do some refactoring, try some of these approaches:

Watch for Stylistic Inconsistencies

Lots of conventions (like variable casing, indentation, etc.) are decided either explicitly or implicitly at the start of a project. These can be enforced with linters, but they’re still worth tracking down and fixing.

More interesting are the kinds of conventions that work their way into our code organically without any explicit decision making. These can be as simple as variable naming conventions or as complicated as the patterns selected to solve certain types of problems.

Event handlers are a class of functions that often get similar names. Make sure your project doesn’t have ‘clickHandler,’ ‘handleClick,’ ‘click,’ ‘clickEvent,’ ‘onClick,’ etc.

Index variables in iterators often end up following a convention in projects, too. Sometimes it might be ‘index’ or ‘i’ or something more specific to the collection being iterated over. Once a convention establishes itself in your project, make sure you keep it consistent everywhere.

More subtle conventions can also assert themselves. File naming commonly follows a pattern, as does the directory structure. The way code is arranged can also follow patterns. It’s not uncommon to see class variables and methods appear before instance variables and methods.

Look for Dead Code

Dead code is code that isn’t needed anymore but never got deleted. Sometimes, it’s in a branch of an if statement that’s impossible to reach, or an event handler that isn’t wired up to anything, or even an entire class that’s declared and then never used. Some of these can be detected by your compiler or linter, but others are more difficult to find. A lot of them can be discovered by searching the project for method names or class names to find usages.

If you find something that doesn’t look like it’s being used, it might be smart to check the Git blame to see when it was last modified, and then look at the rest of that commit. You might find usages that hint at its original purpose.

Make Sure Helpers Are Being Used

Every project winds up with helpers for dealing with simple, but often-repeated, tasks. It’s easy to forget that these helpers exist, especially when the task at hand is simple enough. In the interest of avoiding code duplication, it’s important to remember to use them.

Also, if you see something being done in multiple places and it looks similar to the other helpers that exist for the project, it’s probably safe to pull it out and add it to the helpers, too.

Implement New Patterns in Old Code

As time goes on and languages change, new features and patterns emerge that make our lives easier. An old code base that never gets refactored but constantly gets added to might have some parts that use all the latest, cutting-edge features, while other, older parts might look archaic. Take time to update the older code so that it’s consistent with the newer code.

For example, in JavaScript, we originally dealt with asynchronicity by passing around callbacks. Then we moved on to promises, and now we’re moving on to async/await. If your code base is doing all three, it’s time to refactor.

Regularly taking time to look for these small opportunities to refactor will help set the groundwork for larger and more complicated refactors, and keeping the codebase clean and consistent will contribute to overall ease of development.