Creating a habit: Refactoring
For more visibility posting this on medium. The original article is posted on my website. :)
I want to start this blog with Kent Beck quote
I am not a great programmer. I am just a good programmer with great habits
Having these great habits while developing software is essential. These habits show your commitment to your work and the quality of the software you want to deliver.
In this blog, we are going to talk about one of those habits. Refactoring. Before we start, I wanted to mention that most of the techniques I’ve described here are taken from the book Refactoring by Martin Fowler. I’ve just tried to add my experience on top of it.
So let’s get started.
What is Refactoring?
There are many definitions of refactoring. The official definition says
Changing the internal structure of software to make it easier to understand and cheaper to modify without changing its observable behavior.
But to me, refactoring is a set of technique which helps to improve the design or readability of existing code without losing its existing behavior.
Why do we need Refactoring?
The need for refactoring can be different based on the project or developer context on the code. It can be to fix bugs or to understand the code or want to make code faster. For me, it’s improving existing design or to make code easier to understand.
- Improve existing design: Nowadays technologies and requirements change so fast that the design decision you made 6 months ago does not make sense now. Either requirement changed or you wanted to add a new feature or the framework you use has better ways of doing things now (Every part of the code does not need to be refactored. Look for a refactoring that adds business value). To cope with this constant change we need refactoring or else the code will become harder to maintain and starts to rot.
- Easier to understand: We spend more time reading code than write. Hence we need to write code in a such way that other developers can understand it easily. This is one of the easiest refactoring which can be done to make code readable. Sometimes we refactor to get familiar with the code which is called Scratch Refactoring.
Why do we need to create Refactoring as a habit?
Now you might be wondering, why we need to create this as a habit? Shouldn’t it be a standard thing? Shouldn’t be part of the software development cycle?
Yes, you are right. But even after it’s being part of the development cycle, from my personal experience most developers don’t do it regularly. They try to avoid it most of the time. There might be different reasons, but from personal experience following are the reasons.
- Lack of tests: No test to verify that the changes you made are not breaking anything.
- Deadlines/Time: Strict deadline to complete the feature/story/task which does not give time to improve the design.
- Fear: Fear of breaking other developer’s code, code conflicts, or bringing the whole system down.
- Code Review: To avoid discussions in code review or it can be completely ignored if PR is huge.
- Design analysis: Lack of experience to find design flaws.
How to create refactoring as a habit?
1. Start Small.
This is one of the simplest task, but not easy.
Having a big picture in a mind is a good thing. But trying to do all those changes at once will most probably fail. This also demotivates us to refactor. Previously I’ve shared a similar experience [1].
The goal here is to create refactoring as a regular habit which should be easy to achieve. Hence start small with easier and simplest task.
Make it so easy you can’t say no.
-Leo Babauta
You can start with renaming variables, functions, and classes by giving a meaningful name which makes code easier to understand. Or Extract condition into function and give a function a meaningful name.
Do this regularly and this small refactoring will compound over time and will become a habit.
2. Avoid BIG changes.
Doing big is a motto nowadays. No one wants to start small. Avoid this temptation of big change all at once. This will create more problems.
I used to have this issue in the beginning. Sometimes I still do. Try to move a big package or extract a big function or a class that breaks a lot of code.
But over time, instead of getting demotivated, I tried to learn from it. Why I cannot extract this function? What dependency it has? Can I start with extracting small functions?
Questions like this will help us to analyze the design flaw and the dependencies which will lead to thinking of starting small.
3. Slow progress is still progress.
We are living in an instant gratification era where we want good results quickly. When we start with small refactoring we progress very slow to our goal. Sometimes it takes 3–4 iterations of refactoring, maybe 3–4 stories, or even 3–4 releases to get to the expected result.
At that moment it seems like a waste of time. Just be patient and keep doing it. Remember this, slow progress is still a progress.
4. Breaking Changes
Previously I wrote about finding the right balance between refactoring and over refactoring. If your refactoring has breaking changes like changing a public method signature of the library or breaking someone else work then you need to communicate with your team well before you start.
Most of the times it happened to me that I want to refactor some part of the code which might break the API then I discussed it with my teammates and most of the time I get a better solution without breaking changes.
Leverage Tools
Tools amplify your talent. The better your tools, and the better you know how to use them, the more productive you can be.
- Andrew Hunt, The Pragmatic Programmer.
Everyone uses an IDE. Developers love to debate on which IDE is the best. I am going to be biased with JetBrains IDEs here.
JetBrains IDEs offer way more than just code completion. They are bundled with many refactoring tools which does our job easily. So I am going to share some of the refactoring tools which I used most on daily basis.
If you are new and feel overwhelmed by using shortcuts then I suggest starting with the GUI tools, once you get used to it then look for the shortcut and keep practicing it. The IDE will show the associated shortcut for the action or you can use Key Promoter plugin. Mastering shortcuts this way will boost your productivity.
Refactoring tools I used in IntelliJ
1. Rename package, file, class, variable and methods.
2. Extract methods and parameters.
3. Move package, file, class, variable and methods.
4. Change Signature of a method or class.
5. Introduce variable
6. Multiple Caret Selection
7. Surround with code fragment
8. Extract interface
Did you know JetBrains launched the first IDE in 2000 called “Intellij Renamer (Java)”. The only job it has was to rename class, method, and function. Jetbrains: A company that was built from a simple refactoring tool.
Learn from refactoring mistakes.
Whatever I wrote in this blog is because of many mistakes I did initially. Sometimes I still do. Many times I’ve broke builds, tests, and even other developer’s code. But instead of giving up, try to learn from the mistakes.
I’ve learned over time “How NOT to refactor” which contradictory leads to “How to refactor”
Initially, you will do a lot of mistakes while refactoring. Don’t let those mistakes stop you. Learn from your mistake or other people’s mistake.
Practice, Practice and Practice.
If you want to be really good at refactoring then Practice, Practice, and Practice. There are many ways you can practice it.
- Start with your codebase: Look for code that needs design improvement or needs to be more readable
- Refactoring Katas: Solving these katas will improve to refactor in smaller steps and also refactoring frankly, ugly code into a paradigm of elegant, readable, extensible design.
- Open Source Projects: Find a small, unmaintained open source project on GitHub and look for code that can be improved or need a bug fix. This doesn’t just practice refactoring, but other skills like code reading, testing, and dealing with build processes.
- Read books: I would highly recommend you read Refactoring: Improving design of existing codebase. It will help you understand the mechanics of refactoring with many tested techniques and steps to be followed. Because… Theory without practice is empty, practice without theory is blind. So first practice and then learn the theory behind it.
Note: If don’t find any open source project then you can start with my project i.e PhotoEditor, WhatTodo, and YoutubeUX.
Thanks to Ragunath Jawahar for reviewing this article.
Thank you for taking your time to read this article.
In case of any question, you can reach me on Twitter or Email me.
If you like this kind of content then you can subscribe to my blog and be the first one to get notified when any new content is published.
If you like this article, please like and share it with your friends/colleagues and help me to spread the word.
