[Refactoring 101] Hello Refactoring!
Start from this blog post, I will write What I Learned series regarding the book that currently I read — Refactoring: Improving the Design of Existing Code Second Edition by Martin Fowler with contributions by Kent Beck. The idea of writing this blog post series is to cultivate a better understanding of the resource that I am using right now — by reading, coding, writing, and getting feedback from you.
“To know and not to do, is really not to know. To learn and not to do is not to learn. In other words, to understand something but not apply it is really not to understand it. It is only the doing, the applying, that knowledge and understanding are internalized”
— The 8th Habit by Stephen R. Covey.
As a preface, let’s imagine you open up a small library in your city. You have designed it in the way that you have put the books on the designated shelf.
By the time, your library’s popularity grows up. You order a ton of new books. Since your daily job as a librarian has been busy enough to do other stuff, you just put them on the place that you feel it is the right one.
Then you started to realize — your library is too messy. The result? It is too hard for you to find a specific book.
Some idea may be appeared — such as re-arrange the book. However, without a proper strategy, instead of making it better, we only make ourselves become confused and set we back days, even weeks with no result.
This is an alternative explanation of what programmer may face on in the continuous product development process.
When we reach this level of messiness, we usually hear the idea of refactoring. But be careful, we need to be able to differentiate between refactoring and re-architecting.
Refactoring does not alter any external behavior — such as the input to, and the output from our system. The idea of this methodology is to improve our internal system’s code structure. It is a disciplined way to tidy up our code in order to minimize the chances of introducing bugs when we are developing a new feature, and also help ourselves (and our team) to iterate faster on developing that new feature.
An experienced programmer may have an idea of design-first approach where they properly architecting on how their structure code should be. This idea may be good at some degree because they do not want to repeat the previous mistake on their new system.
However, keep to be remembered that over time the code will be modified, we will not be the only one who handles the system. Not only that, the business requirement and direction might be changed. Hence, the integrity and structure of our system will gradually fade, and our job will transform — from engineering to hacking the code.
“As we build the system, you learn how to improve the design. The result of this interaction is a program whose design stays good as development continues.”
— Martin Fowler
Refactor should be done as a part of your development cycle. However, refactoring is risky. It requires changes to the working code that can introduce subtle bugs. If we are not doing the methodology of refactoring properly, instead of clean it up — our code may become messier. Also, we waste several days/weeks with small outcome.
Refactoring may become riskier when we do it informally without any proper strategy or ad-hoc. At most cases, using a pre-defined and validated approach is better than introducing your own methodology.
In order to reduce that risk, you need to have test cases. Testing would be an integral factor in refactoring — to make sure everything still works like before and you still on the right track to clean up your code instead of introducing breaking changes to your system.
On the next blog post, I will write more about The Essential Steps of Refactoring Cycle. For the next chapters from the book, I will start to share some code on my Github around refactoring methods.
Thank you for reading this blog and I am happy to hear your feedback.
Surya is a Software Engineer in his professional life and a Technology Evangelist in his personal life. This year, he builds a resolution, called “Learn to Unlearn and Keep Sharing”. If you are interested or want to follow his progress, you can visit him at his personal website, soensurya.com, or on LinkedIn.