- [Instructor] Before we attempt any type of refactoring to a codebase, it's important to create a baseline so we know where we're starting. A baseline is a minimum or starting point used for comparisons. This becomes critical over time as you refactor pieces of code and need to compare it to the previous version, or if you mess up, being able to go back and revert to the original codebase. Some of the advantages of creating a baseline is that it offers a single stable build of your codebase to revert back to.
It also enable others on the team to still work with the main codebase without being affected by the refactoring. Remember, refactoring really is about cleaning up the underlying code and not the existing APIs, so it should be possible to refactor a codebase while others are working on it without affecting other members of the team. And finally, the baseline ensures you have a point of reference to backtrack in case refactoring goes wrong. Remember, it's okay to make mistakes when refactoring.
Sometimes refactoring can break your codebase. That's why it's important to do refactoring in small, controlled steps and revert to the baseline when things become unfixable. There have been many times where I've been working on a large refactoring and I've gone and broken most of the code and couldn't figure out how to backtrack and get out of it. While it may have taken me hours to do the refactoring only to find out that I couldn't get anything salvageable out of it, it was still a good learning experience, and I encourage you, when you make a mistake, don't be afraid to revert back and try again.
Use the things you learned during the first round of refactoring to hopefully not repeat the mistake when you attempt it another time.
- Creating a baseline
- Removing unused code
- Refactoring in branches
- Using refactoring tools
- Optimizing code
- Creating clean code