Lessons and takeaways on Refactoring
Refactoring is the key to be able to build quality software quickly.
Just a guy who loves to write code and watch anime.
I finished reading the book "Refactoring: Improving the Design of Existing Code" by Martin Fowler and wanted to share some of my lessons. 💙
First, I want to say, this is one of the books I actually classify as a "must-read", it even includes modern examples in JavaScript which I loved as someone who works heavily with JavaScript 😁
Lessons and takeaways ✍️
1
When you have to add a feature to a program but the code is not structured in a convenient way, first refactor the program to make it easy to add the feature, then add the feature.
Adding the feature first, in this case, would cause more complexity and make it harder to refactor and add new features later.
2
Before you start refactoring, make sure you have a solid suite of tests. These tests must be self-checking.
You can't refactor with confidence if you don't have tests: eventually you'll find yourself not refactoring, rather debugging for hours.
3
Refactoring changes the programs in small steps, so if you make a mistake, it is easy to find where the bug is.
Refactoring is a practice where we take small steps. Refactoring is rewriting code, but rewriting code isn't always refactoring.
We make small changes and along the way run the tests.
4
Any fool can write code that a computer can understand. Good programmers write code that humans can understand.
If other humans, other developers, can't understand the code I write, then how will we as a team be able to maintain and change the software?
5
When programming, follow the camping rule: Always leave the code base healthier than when you found it.
Refactoring should be a habit of every team member. Always leaving the code cleaner than you found it goes a long way.
6
The true test of good code is how easy it is to change it.
Have you seen code you were scared of touching?
I have.
The code is scary because it's both hard to understand and modify without breaking things.
Good code should be easy to change, easy to debug, and easy to add new features to.
7
Each individual refactoring is either pretty small itself or a combination of small steps. As a result, when I’m refactoring, my code doesn’t spend much time in a broken state, allowing me to stop at any moment even if I haven’t finished.
When refactoring, we don't want to spend much time in a broken state, and somehow suddenly put ourselves in a position of debugging.
Don't forget, the main goal is to improve the existing code, not put yourself in a worse situation.
8
If someone says their code was broken for a couple of days while they are refactoring, you can be pretty sure they were not refactoring.
In this scenario, the person wasn't refactoring, rather somehow tried rewriting the code and put themself in a situation of debugging.
9
By putting our effort into a good internal design, we increase the stamina of the software effort, allowing us to go faster for longer.
Managers or other people may complain, or wonder why we should not just refactor, but why do it often?
By consistently improving the existing code, we consistently make it easier and faster to change the existing code and adding new features to it.
10
Software developers are professionals. Our job is to build effective software as rapidly as we can. My experience is that refactoring is a big aid to building software quickly. If I need to add a new function and the design does not suit the change, I find it’s quicker to refactor first and then add the function.
Refactoring is the key to be able to build software quickly.
11
The whole purpose of refactoring is to make us program faster, producing more value with less effort.
In some situations, you may find that refactoring before adding the feature would take longer than first adding the feature. If you have a fixed date, a deadline, then in such situations it is better to postpone the refactoring, and refactor after the feature has been added.
12
When you feel the need to write a comment, first try to refactor the code so that any comment becomes superfluous.
Comments add more noise, there is more to maintain, even worse, comments that are outdated or bad can be extremely misleading and confusing.
Try to avoid comments when possible, if you really need comments, they should be there to explain the why.
I strongly advise reading this article about comments in code by my friend Rodrigo.
Conclusion
Refactoring is extremely important if you want to build quality software.
Do it often.
Do it daily.
