There are Two Ways to Refactor
At my job we have recently brought our second client into production with a SAAS (Software as a Service) that we have been developing over the past year and a bit.
Old post from 2020.
At my job we have recently brought our second client into production with a SAAS (Software as a Service) that we have been developing over the past year and a bit. The application required some fairly substantial refactors and logic changes as we transitioned from building a non configurable application to a configurable one, with more functionality, that can support both our clients and new clients. With the first few modules of the SAAS complete we now find ourselves with an opportunity to clean up our code and complete some other refactors around the application.
Refactors are a natural requirement when you are building software. Requirements change, decisions are made, and features have to be finished in sometimes short periods of time. As this happens the code can/will develop code smells and it is the responsibility of the developers to reserve the time to fix these.
As we plan these refactors we want to make sure that they do not block developers from completing other work and that the work can be shared across the entire team. However, some refactors are best done from start to finish in one fell swoop while others are best planned and then dispersed to the team. I’m here to talk about those two refactor approaches.
The main reason that you would want to complete a refactor all at once is that you can be sure to find all of the edge cases that you may not have expected before you complete the refactor. Edge cases come up ALL the time when refactoring. You may begin diving into a refactor where you’re going to take 20 different components across the application and you’re going to standardize them. You start by evaluating the existing components to try and figure out the best approach for the refactor and to find all the scenarios across them. You then begin working on the refactor and implementing it across the components but on component 18 you find an issue that you don’t understand how you could have possibly overlooked :O. You now have to re-evaluate a small or perhaps large portion of your code and implement it across the past 17 components you just worked on. This may not be a big task but sometimes it can be and if this work was shared across multiple developers then at some point one of those developers, perhaps a junior, may run into that issue. Upon running into it they may implement a hacky fix for it which then may develop into another code smell in the future if it’s not caught in the code review process, which I hope it would be. When sharing refactors across the team it is important to do thorough research to try and catch as many edge cases as possible before implementation. However, I want to re-enforce the fact that all refactors require planning but edge cases will still come up when you don’t expect them to which is why completing a refactor all at once can be beneficial.
The main reasons you would want to setup a refactor and share it among the team would be to save the time of senior developers and to allow everyone to understand the new standard that is developed with the refactor. When doing a refactor like this, you need to implement the new standard in such a way that the old implementation style still works until the new standard is implemented across the application. At that point you can delete any code that was only used to maintain or implement the old standard.
Sharing refactors among your team members is great as it allows everyone to understand the new standard but sometimes it can cost more time to implement overall with the up front research and the possibility of unexpected edge cases. Sometimes having a single developer complete a refactor is great as all edge cases will be found by the time it’s complete and it may be completed faster. It’s up to you to decide how and when refactors should occur. It is a natural requirement of software development and it is up to you to determine if the refactors are bringing value to the company and team. Perfect code isn’t real but hopefully this article can help you approach refactors in the future.