Refactoring is the process to make existing code beautiful by restructuring it. It doesn’t add features and change its behavior. It’s one of the clean-ups. The software quality becomes basically better if the refactoring process is in the development process because the code becomes more readable. If the code is readable it’s easy to find a place where you need to modify and consider how to implement it. As a result, the number of bugs decreases, and the development cycle runs faster. That’s why refactoring is important.
Let’s see the necessary knowledge for refactoring.
When to refactor
I think refactoring should be one of the daily works because a software developer read code every day. It’s the easiest time to refactor when you find codes where you can make them better because you know the code the best at the time. The basic rules to refactor the code are the following.
- Before adding new features
- Right after you add features or fix bugs
- After release
- While adding new features
Before adding new features
You may already have an idea of how to implement a new feature or how to fix a bug but the current code looks not the best. Refactor the code first in this case. Its process makes you understand the code better and you may be able to come up with a new idea. However, it’s not a good idea to refactor if you’re not sure which classes should be modified for the new feature. We should refactor the code only where we have to modify it for the new features or bugs. Otherwise, the refactoring doesn’t finish.
Right after you add features or fix bugs
I mean this is the timing after the PR is approved and the target code is merged onto the master. You already know where you should refactor. You are still flesh to the code, so it’s not hard to refactor. If the tests are not enough you can add the additional tests by refactoring.
After release
You may not have enough time to refactor your code. If you think so you should write down “technical debts” in a place that other members can access. You may need to fix bugs found after release but you have more time than before. It’s good timing to tackle the technical debts.
While adding new features
I often refactor in this timing after the light behavior check because I first want to check if my idea works. It’s clearer which code to modify because there is already actual code. Don’t get me wrong. I don’t break existing features here. I do the refactoring where the tests exist for the existing code. However, I also refactor the code where I added the new features before or after writing the test. It depends on the case. New features are tested correctly and existing code is improved in this case as well.
Switching modes between refactoring and modification
It’s important not to change the behavior and not to refactor at the same time. Focus on refactoring when you refactor. You shouldn’t change the behavior then. If you want to change the behavior you should commit the source code first and then you should start changing the code.
Some say that we shouldn’t refactor in the same PR but it makes our work slow because we can not always implement the new feature without refactoring.
Test first? Actual code first?
Red-Green refactoring (TDD)
Some prefer writing tests before changing something. It’s the test that tests the refactored code but it of course fails before refactoring. You decide the behavior first and then refactor it. You write many simple tests, so the production code is well structured. In addition to that, you can check the behavior right after you write the target code. It makes your work slow until you get familiar with TDD and learn many patterns.
Actual code first, then test
I personally prefer this way because I don’t have a clear picture before coding. I try to find where I can make it better in the new code right after adding it. We don’t have to amend the test code many times if we have code first and change it until we are satisfied with it. That’s why I prefer this way and we can implement it in a shorter time than TDD.
What skills are required
We need to know many patterns for refactoring. The following post helps you know 5 techniques that you can immediately apply to your code.
If you want to learn comprehensive refactoring techniques I highly recommend this book on the left side below. This book explains step by step so all developers can easily understand the process and how it works. It focuses on small things while another book on the right side focuses on class relationships. If you don’t know design patterns well you should have one of these books.
Goal of the refactoring
The goal of refactoring is that the code is better than before the refactoring. It doesn’t always mean that you have to split a class or function. Sometimes it’s just changing a variable name. Sometimes it’s adding classes. There are many better ways for the code and it depends on your idea of how to refactor it. The goal is not to make the code The BEST. It’s to make the code better than before. It’s ok even if the number of code changes is 1 line if it makes the code better. Its 1 line change makes the code much better after a while.
Comments