My 7 Takeaways From the “Refactoring: Improving the Design of Existing Code” Book
What I learned while reading the Martin Flower book
As software developers, we should embrace change. Frameworks change, requirements change, expectations change… Incorporating those changes into the existing code base is not always easy. But, writing clean and well-structured code will make it easier for your future self.
As developers and designers, or even as humans, we do not always make the best decision in the beginning. Sometimes it helps to see where this journey is taking us and then we revise our previous decisions. The more considerate we are for those future revisions the easier it will be to apply them when the time comes. It is almost always the case for software development. Refactoring is the way we revise our past decisions for our software.
I would like to share my top takeaways from the book Refactoring by Kent Beck and Martin Fowler. The book shares invaluable practical ideas about refactoring. There is also a catalog of many refactoring techniques illustrated with amazing examples. Definitely recommend reading the book to anyone interested in learning more about refactoring.
The first chapter is an example of refactoring in action. It justifies the actions taken and shares many useful rules of thumb.
1. Aim to Embrace Change
The idea that the software we code is dynamic brings the implicit necessity to change.
To apply the next change with ease we first need to have a good structure in place.
Refactoring aims to improve the structure of the code without affecting any observable functionality.
2. Make Sure You Have Enough Tests Before Refactoring
When refactoring the code we want to make sure the software keeps working as expected. The best way to achieve this is with the help of a good set of tests.
Tests ensure that no matter what we change the functionality remains the same. We must make sure that our tests cover the areas we touch during refactoring.
If they do not, we must stop now, and start adding those tests before even starting to rename a single method.
3. Refactor in Small Steps
Refactoring may break things and this is why we wrote the tests first, right? Right? Okay. We should make changes in steps as small as possible and test those changes.
This way we know what and when we messed up and it is easier to revert as our step was small.
4. Have a System: Refactor, Test, Commit
No matter how careful we are, having a system when refactoring will help with the process.
When you refactor, you refactor in small steps. You test your changes. And then, you commit that change to your favorite version control system. Now you have a clear history of well-tested changes! Thanks to this process, you can:
- Revert to any of those commits with 100% confidence,
- Stop whenever you like and release any commit and it will be an improvement, and,
- You can squash those tiny commits into larger more meaningful commits for a good-looking history!
5. First Refactor, Then Extend
Refactoring before adding new functionality will help with the thought process. And leaving the codebase better than you have found it is a bonus!
6. Use Descriptive Names when Renaming
Renaming is a crucial technique in refactoring. Renaming variables, renaming methods, renaming classes… The point of renaming should be to use descriptive names that save us time.
A good name for a variable saves us from reading how it got here to understand what value it holds. A good name for a method saves us from reading its entire implementation to understand what it does. A good name for a class saves us from reading its entirety to understand its responsibility.
Spending a good amount of time and effort to choose a name is at the heart of refactoring. Otherwise, what would be the point of splitting a large method if we still had to read the smaller ones?
7. Keep an Eye on Performance when Refactoring
Performance might get affected during the refactoring process. Even if it does, it usually does in small scales with no significant loss. But, it is a good habit to take note of possible performance degrading points.
After completing refactoring, we should review those points and fine-tune for performance. It is going to be easier to fine-tune as the codebase will have a better structure at the end of refactoring.
Originally published at https://recepinanc.com
