Seven things to keep in mind before starting your next refactoring project

Franco Fernando is a software engineer and technology enthusiast known for his expertise in web development and mobile applications. Readers can learn about coding best practices, software architecture patterns, and emerging technologies. With articles, tutorials, and code samples, Franco Fernando shares  insights and expertise for building modern and scalable software solutions.

The Polymathic Engineer

Refactoring code requires careful preparation and the right mindset to avoid common pitfalls. Key considerations include understanding the existing codebase thoroughly, resisting the urge to rewrite everything from scratch, making incremental changes, preserving existing tests, checking your motivations for refactoring, evaluating technology changes carefully, and accepting that refactoring projects can sometimes fail. The difference between successful and failed refactoring often comes down to proper planning and approach rather than technical skill alone.

Before refactoring

Resist the Temptation to Rewrite Everything

The argument I’ve always made for (or against) refactoring is based on a single question: Does the code do what I need it to do, or do I simply not like how it’s designed? Ultimately, my ethos is that working code always wins. I’ve come across tons of “oh, I hate how you did this” code, but it does what I need. The moment that code cannot do what I need, or cannot be easily modified to meet a new need, it’s refactor-o’clock. But then you have to decide what type of refactoring to do? Are you a “Scout” or a “Marine”? The “Scout” is taught to “leave it better than you found it,” the “Marine” is taught to leave no trace.

I agree that it’s essential that refactors should always result in a net technical improvement.
I’ve found it’s helpful to frame refactoring discussions around business value. For example, is making an endpoint incrementally faster truly necessary right now if it doesn’t solve a user-facing problem? Maybe not. But if a refactor makes it possible to ship future features faster or improves system stability by reducing bugs caused by fragile architecture, then the business case is clear.
Connecting the technical improvements to tangible business outcomes helps motivate the refactor.