I am tasked to refactor an entire codebase (in React) and initially, I am thinking of refactoring just by type as in, e.g. “Remove all unused comments”, “Rename methods more clearly”, etc.
However, I am thinking whether a Component approach would be better as in, I do the refactoring by Component first and then do individual types of refactoring per component, e.g. “Login component - Remove all unused comments”, “Login component - Rename methods more clearly”. Then after “Login” is pretty much “clean”, then I can move to another component and do the exact laundry list of refactoring. This way, I think it’s easier to test / make lesser mistakes.
Then after all the individual Components are done, then I’d move into the structural refactoring, as in those kinds that will affect the interactions between different components (e.g. restructuring file folders, changing the state management library, etc.)
So here is my plan:
- Functional / presentational Components
- Class-based Components
- Overall hierarchy / folder structure
Just asking anyone else’s opinion on the matter? Or any other tips and suggestions?
Removing comments and renaming functions is not really a refactoring
The question is “why do you need to refactor an entire codebase”? Just because, or is there a reason? If the whole codebase needs refactoring wouldn’t it be better to just rewrite it from scratch?
What @jenovs wrote: what you are describing are cosmetic changes. By all means do them as a chunk of work (rather than just deleting/renaming/moving stuff when you notice something). But if so just do them, they aren’t things you need to think about much.
There’s only one thing there that is really refactoring, and it is a big thing, you need a really good reason to do it, and you just kinda toss it in like it’s nothing:
e.g. restructuring file folders, changing the state management library
That would affect the architecture of the whole application.
Ok, I mean those are just a few examples and the lowest hanging fruit, so to speak. There are other things that need to be refactored like deeply nested if-then statements, shortening very long methods, repeated logic, changing non-stateful class components into functional components, etc. They need to be refactored because the application was done last time with a tight deadline so “clean code” wasn’t the main priority. But we are moving towards better engineering standards and our codes must be easily readable and maintainable.
Do you think it’s best to do these changes on a per component basis rather than on a ‘type’ basis?
I am aware of the refactoring that would change the entire application’s architecture, that’s why I put it as one of the last things. It’s on the pipeline, however, it may not be the main priority as that would be a ton of work and a lot of tests should be in place.
It should be done on basis of need/feature/etc. Just “type” or “component” doesn’t really work because beyond cosmetic changes, you’re going to run into cross-cutting concerns very quickly. But of the two, “component” is much better, because you can clean them up one at a time.
Rewriting is often a bad idea, but if you know how it all works, building it back up from a clean slate is possibly a better idea. I’d say the three main things that will help with this process, regardless of what you do, are:
- Write tests
- Write tests
- Write tests
Also, apply a code formatter (ie Prettier). And apply a strict ESLint config, then fix all the warnings you can.