12 Refactoring Rules of Thumb

It’s easy to refactor messy code once you follow a few simple guidelines

I’ll start by providing you exactly what you came for: the rules of thumb.

Are you curious about why these heuristics are useful? Then read the additional information included after the list.

12 Heuristics for Beginners to Become Refactoring Experts

Let’s dive headfirst into the matter. This list is a mix of heuristics I always have in the back of my mind when I venture into a refactoring session.

1. Is your class’ list of parameters starting to grow too big? Then it’s likely doing too much. Its responsibilities are unclear and perhaps painful to test and debug. It’s a prime candidate for refactoring.
2. Do you have methods inside classes that only use one of the class dependencies? You better pull that method into a class of its own — even if that class will only consist of a single method.
3. Is your method doing two different things depending on a boolean parameter value? Why not just create two different methods with clear responsibilities?
4. Is your method branching over a value? Say, for instance, you’re checking the type of an object and perform different operations based on its type. This is a great time to turn your if-else or switch into a dictionary or map.
5. Do you use if-else or switches extensively throughout your code? Try using polymorphism instead and apply battle-tested design patterns like Strategy, Mediator, etc.
6. Does your class constructor or method take a “magic” number or string? That is an arbitrary value representing some intrinsic business value. Replace the magic with enums.
7. Do you have hard-coded values (numbers or strings)? Take the values as parameters instead and let them be configurable. It becomes easier to reuse or deploy your application in new environments or change settings.
8. Don’t use variable names like i, j, k, m, n, x. Just stop it.
9. Do you find yourself implementing the same piece of logic in multiple places? Move the logic to its own class or method.
10. Do you have Service or Manager classes? They’re like Swiss Army knives. Lots of responsibilities, low cohesion. Take a minute to think about which services they provide and then move each distinct service into a class of its own.
11. Do you find it challenging to test a single method because the class it lives in takes a lot of constructor arguments? Break the method free from its class.
12. Do you have to add a new else-if or switch case to implement a new requirement or feature? Try using interfaces and reflection to discover types automatically.

Why It’s Worth Spending Time Learning Refactoring

You’re an aspiring developer on your journey to mastery. Learning to refactor code — and more importantly, recognizing when to refactor code — is an essential skill.

Knowing when to refactor is paramount. Too early? It’ll just be premature optimizations. Too late? Your codebase is a pain to deal with.

I’ve seen great developers skip refactoring when they shouldn’t have. Their code came across as mediocre because of entangled responsibilities and low readability.

There’s a time and place for refactoring. Sometimes, it’s not required at all. What’s needed is completely nuking the code and starting from the ground up.

What Exactly Is Refactoring?

Let’s take a moment to get on the same page.

Refactoring is, fundamentally, behavior preserving changes to the codebase. However, it’s commonly interchangeable with fixing bugs, adding new features, and tweaking performance.

Inexperienced developers often misuse refactoring sessions to tweak and alter behavior — or even to make it work. That’s not refactoring. That’s bug-fixing and performance optimization.

How Does Refactoring Improve Internal Software Qualities?

Refactoring code is all about bettering your application’s internal software qualities. You’re improving one or more of seven different quality characteristics:

1. Maintainability — Improve how easily you can make changes to your software. Maintainability includes adding new features, tweaking performance, ease of bug-fixing.
2. Flexibility — The extent to which you can modify your software for other uses. Think about how easily you can pivot the software.
3. Portability — How easily you can make the software operate in another environment. Think about local development vs. running on a server in production.
4. Reusability — How easily you can use parts of your software in other systems.
5. Readability — How easily you can read and understand the source code. Not only on an interface level but also the nitty-gritty details of implementations.
6. Testability — How easy it is to write unit tests, integration tests, etc.
7. Understandability — How easy it is to understand your software on a general level. Is your codebase structured in a meaningful manner?

Some of these characteristics achieve conflicting goals. That’s life.

Consider which qualities your refactoring session aims to improve, as it can’t improve every single one of these.

With these characteristics in mind, test your knowledge and see if you can map them to the list of heuristics.

Which heuristic improves which quality characteristics?

Resources

• Code Complete 2 by Steve McConnell
• Is Optimization Refactoring by Martin Fowler

Nicklas Millard is a software development engineer in one of the fastest-growing banks, building mission-critical financial services infrastructure.

Previously, he was a Big4 Senior Tech Consultant developing software for commercial clients and government institutions.

New YouTube Channel (@Nicklas Millard)

Connect on LinkedIn