My Top Takeaways From Refactoring: Part 1

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 designer, 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.

Chapter 1 - Refactoring, a First Example

The first chapter is an example of refactoring in action. It justifies the actions taken and shares many useful rule of thumbs.

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 structure of the code without effecting 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 change. Finally, you commit that change into 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 a larger more meaningful commits for a good looking history!

5. First Refactor, Then Extend

Refactoring before adding a new functionality will help with the thought process. And leaving the code base 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 saves 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 effected 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 code base will have a better structure at the end of refactoring.

Conclusion

Thanks for reading, that’s all for Chapter 1! I hope you find these points useful as I do. And, stay tuned for Chapter 2!