What I Learned While Reading Martin Flower
As software developers, we must embrace change. Frameworks change, requirements change, expectations change… Integrating these changes into the existing code base isn’t always easy. But writing clean, well-organized code will make it easier on yourself in the future.
As developers and designers, or even as human beings, we don’t seem always make the best decision in the beginning. Sometimes it helps to know where this journey is taking us and then review our past decisions. The more we consider those future revisions, the easier it will be to apply them when the time comes. This is almost always the case for software development. Restructuring is how we review our previous decisions for our program.
I would like to share with you my most important conclusions from the book Refactoring by Kent Beck and Martin Fowler. The book shares invaluable practical ideas on rebuilding. There is also a catalog of many reconstruction techniques illustrated with amazing examples. I definitely recommend reading the book to anyone interested in learning more about rebuilding.
The first chapter is an example of rebuilding in action. It justifies the actions taken and shares many useful general rules.
The idea that the software we program is dynamic brings the implicit necessity of change.
To easily implement the following change, we first need a good architecture in place.
The refactoring aims to improve the structure of the code without affecting any observable functionality.
When refactoring the code, we want to make sure that the program continues to run as expected. The best way to achieve this is with the help of a good set of tests.
The 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 rebuilding.
If they don’t, we should stop now, and start adding those tests before even starting to rename one method.
Refactoring might break things which is why we wrote the tests first, right? right? OK. We should make changes in as few steps as possible and test those changes.
This way we know what and when we went wrong, and it’s easier to go back because our step was small.
No matter how careful we are, having a system in place when rebuilding will help the process.
When you rebuild, you rebuild in small steps. You are testing your changes. And then you commit to that change in your preferred version control system. Now you have a clear history of well-tested changes! Thanks to this process, you can:
- Return to any of those commitments with 100% confidence,
- Stop whenever you like and release any commitment and that would be an improvement, and,
- You can crush those little commitments into bigger, more meaningful commitments for a good-looking date!
Refactoring before adding new functions will help the thought process. Leaving the code base better than what I found is a bonus!
Renaming is a critical technique in debt reconstruction. Rename variables, rename methods, rename classes… The point of renaming should be to use descriptive names that save us time.
A good variable name keeps us from reading how it got here to understand what value it holds. The method’s good name keeps us from reading its entire implementation to understand what it’s doing. The class’s good name saves us from reading fully to understand its responsibility.
Spending a great deal of time and effort choosing a name is at the heart of rebuilding. Otherwise, what’s the point of splitting a large method if we still have to read the smaller method?
Performance may be affected during the rebuild process. Even if it does, it usually happens at small ranges without significant loss. But, it is good to note the points that may degrade performance.
After the rebuild is done, we should review these points and adjust the performance. It will be easier to adjust as the blade base will have a better structure at the end of the rebuild.