Lessons and takeaways on Refactoring

Refactoring is the key to be able to build quality software quickly.

Featured on Hashnode

I finished reading the book "Refactoring: Improving the Design of Existing Code" by Martin Fowler and thought of sharing some of that which I've learned ๐Ÿ’™

First, I want to say, this is one of the books I actually classify as a "must-read", it even includes examples in JavaScript which I loved as someone who works heavily with JavaScript ๐Ÿ˜

Lessons and takeaways โœ๏ธ


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.


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, meaning, you will eventually find yourself not refactoring, rather debugging for hours and hours.


Refactoring changes the programs in small steps, so if you make a mistake, it is easy to find where the bug is.

Refactoring is about making small changes, making sure to run the tests frequently, and via small confident steps, improving the existing code.


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?


When programming, follow the camping rule: Always leave the code base healthier than when you found it.

Always striving to leave the code better than you found it goes a long way. Refactoring is something that should be done often, it makes it easier to add new features and makes the existing code easier to maintain.


The true test of good code is how easy it is to change it.

Have you seen code, where you were scared of touching it? I have, that's because the code is hard to change, already by reading such code, we have a hard time understanding what it's doing and how things are working together.

Good code should be easy to change, easy to debug, and easy to add new features to.


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.


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.


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.


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.


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.


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.


Refactoring is extremely important if you want to build quality software.

Do it often.

Do it daily.

Avinash Dalvi's photo

Good learning insights Tiger Abrodi Keep writing while you learning.

Tiger Abrodi's photo

Much appreciated Avinash, I will =D

Kieran Roberts's photo

Good points Tiger Abrodi, I enjoyed reading your article. Keep them coming!

Tiger Abrodi's photo

Means a lot Kieran!

I will =D


Nice information ๐Ÿ˜ƒ Tiger Abrodi

Tiger Abrodi's photo

Thank you Melvin, glad you liked it =D

Maxi Contieri's photo

Great Article, Tiger Abrodi!

Tiger Abrodi's photo

Appreciated Maxi <3

Abiola's photo

Thanks for this article Tiger Abrodi

Tiger Abrodi's photo

Happy to share it! =D

Aspiiire's photo

Really great article!

I found that the most important rule as I read in other books is the one that you have put as the number 4 in this article; A well written code is a must, it makes for you and for others easier to understand what's going on!

To me it seems really similar to "Clean code" Robert C. Martin, Am I wrong? ๐Ÿ˜…

Tiger Abrodi's photo

Many of those technical books cover similar points indeed.

But this is more about refactoring.

Improving the existing code with confidence, by taking small steps and running the tests frequently.

Refactoring allows us to build quality software quickly for longer =D

Rodrigo's photo

Tiger Abrodi is right, but you can also think of refactoring as the means to transform your code into clean code

Mattia Sinisi's photo

Amazing, I've saved and shared this article on LikedIn. Thanks for condensing the book to a one-pager.

Tiger Abrodi's photo

Means a lot Mattia, thank you!

I'm glad it helped <33

Ankur Tyagi's photo

Great article Tiger Abrodi

Tiger Abrodi's photo

Thanks Ankur <3

Catalin Pit's photo

Look who is on Hashnode! ๐Ÿ‘

Glad to see you here! Keep the great articles coming! ๐Ÿ”ฅ

Tiger Abrodi's photo

Thank you Catalin <3

My next article will be one about working with legacy code, I'm roughly half way through the book I'm currently reading and have tons of notes already, really looking forward to sharing the knowledge. =D

I love the Hashnode community.