What is inevitable will always come, sooner or later. In engineering, this applies to refactoring. For those unfamiliar, refactoring is the practice of doing a code quality audit so to speak. An engineer reviews the code, finds ways to streamline it, and then does it. Pretty simple right. Wrong!
Refactoring is a major effort that, depending on the size of the codebase, can be swift or a multi-quarter effort. In worse case scenarios, even years. You may be thinking this, but no, there is no way avoiding the need for a refactor. No matter how clean your code is, there will always be a time when it gets bloated and needs a good trim. That leaves one question though. How do you know when it’s that time?
Identifying Signs
Refactoring just for refactoring’s sake is a never-ending rabbit hole, so avoiding is best for your health and the health of your codebase. With that in mind, the most critical aspect of refactoring is being able to see the signs of when it’s time to delve into this effort. So, what are the signs?
This can be a myriad of reasons, but the biggest one I can point out to you is when your productivity and effectiveness of the developer experience are a pain. This includes duplicate components/logic, various coding patterns, multiple packages/patterns that do the same thing, monolithic classes/functions, etc.
Creating A Plan
Being aware of the areas that need a good refactor is a great start, but it’s like someone just saying they’re hungry. You know the outcome you want, but it takes action to achieve it. We already went over how much of a black hole refactoring really is, and the only way to avoid is to simply create a strategy around it.
This starts with first having a clear objective. Articulating a clear problem area in the codebase gives direction, and measurement to identify success or failure. After the problem is clear, set an end date. End dates are important for refactoring because that is your most reliable guardrail. Without an end date, it makes it impossible to come up with a plan that can efficiently get the job done and actually meet the light at the tunnel. Now after all that, you’ll simply need to stay on task. The hardest part of refactoring is honestly focusing on fixing one thing at a time.
In Closing
Refactoring is simple, yet powerful. It is an important step in the healthy development lifecycle of any project and is needed to keep our applications churning on all cylinders. Don’t be afraid to identify areas that need a refresh or centralization across repos. Take a breather, find the patterns or alternatives, and then take action.