In part I of our refactoring series we talked about what is code refactoring, and why it deserves an investment during development. In part II, you'll learn all about when to choose to refactor, what situations it's absolutely crucial to refactor in, and our teams take on the clean code approach.

Make sure to come back every Wednesday for more tech shorts, how-tos, and deep dives into engineering tools and processes.  

Let's dive right in.

When to Choose Refactoring

Timing matters when it comes to changing directions in software. But generally speaking, one of the best times to try refactoring is before making updates or adding new features to current code. Anytime you clean and refresh code, it provides a more stable foundation upon which to build new functionality. It improves product quality, security, and user experience.

Also, somewhat counterintuitively, refactoring can be a good option right after launching your product on the market. Why? Scheduling, for one thing. Pre-launch frenzies can take up a lot of your developers’ time and energy. Once that settles down and user reports start coming in, your developers can take some extra time and an extra close look at the code and start to refactor and clean it up for future releases before the next big push comes. And because the code is now cleaner and more stable, future features and adjustments will be easier to implement and maintain. In addition to these two moments in an app’s life, refactoring may become an important option during these situations:

A. When support for older technology disappears

Market forces are constantly pushing and pulling technology, and the company that wants to remain relevant and in the game has to innovate constantly. In fact, software is more sensitive to these changes and demands than almost anything else. This makes regular code revamping an absolute must for staying on top of technologies as they grow—and disappear into history.

B. When a huge leap in technology happens

Continuing from the previous point, when a big leap in the way technology works comes along (and it happens all the time these days), refactoring is essential to keeping up with the new. As the new appears, the old disappears, and you don’t want to disappear with it. Refactoring makes it easier to prepare for those sudden leaps forward.

C. When the software is flawed

Dirty, messy code is buggy, dysfunctional code. The process of cleaning it up will necessarily help you remove and correct those issues with cleaner, error-free code that works reliably and saves headaches and resources of all kinds. Clean, streamlined code is good for the whole organization, helping your organization get some real competitive advantages.

Thoughts about Code Refactoring from Our Team

Refactoring is great for improving your architecture and the overall structure of the system. It’s true that refactoring can take a lot of time and resources, especially if you have non-structured blocks where newer pieces are bound up together with older pieces of architecture.

One way to keep things fresh is to do refactoring at regular intervals, renovating the system overall in a step-by-step manner. This constantly enables you to renew obsolete pieces of the system while strengthening security along the way, if done properly, of course. Basically, you want to make it part of a regularly-scheduled routine.

In fact, here at Spark Equation, we decided to rebuild our internal software structures in August 2020 with a desire to refresh older software structural elements.

Why We Refactor

Refactoring produces a better, stronger, more secure, and more stable software product. That’s the "why" of it. We also have recommendations about how to refactor. Instead of doing big chunks of refactoring all at once, we recommend “incremental refactoring”, as shown in the infographic below:

You want to continuously do small refactorings that never stop the delivery rhythm of the team. What that process looks like:

When performing refactoring, you need to have a clear goal, usually centered around fixing code smell. As a best practice, you should implement the process through a list of small steps that are completed in order, and as a result, you receive improved code. Examples of other goals teams have used are - organizing data, handling generalizations, or simplifying method calls.

"After performing refactoring sessions, our clients realized that refactored code helped them improve their products' scalability or get from MVP to adding new features faster and more efficiently."

Curious how your code is doing? We can perform an assessment and highlight all the areas that are a risk and remedies that can be implemented right away. Chat us online or send us a message.

In part III we will discuss warnings before you start refactoring, techniques, and go through a simple step-by-step example to ensure you've got refactoring down. Check back every Wednesday for more content.

Read Part III

‍