A Journey of Refactoring Through My Inner Voice
This year has been my year of refactoring. I have been doing a lot of code refactoring and reading books about clean code, and testing. I have also been listening to many conferences, and so on.…
Of course never enough to learn clean code, refactoring, and tests. It is a bottomless pit.
Now you will listen to my inner voice while refactoring. I’m sure there will be parts that sound familiar to you. These rules I learned made it fun to write code for me and made me write wiser.
1-Be patient
Yes, first thing first, be patient,
Don’t dive into refactoring code directly.
Sit back and know the code can’t escape,
It could be difficult or easy doesn't matter, You are a soldier, Just first stay calm, look at the code, examine it, and check where the code is used.
Refactoring could be long-term and you have time, never, ever refactoring under time pressure.
2-Don’t be afraid
Don’t be afraid to smash the code, edit it delete move it somewhere else…
It’s your code, you own it, not it owns you.
Be a brave soldier.
3-The Code can’t run away from you
This code can’t escape, can’t escape, remind yourself again, again and again. Believe me, when you continue to read my inner voice you will get what I mean.
4-First Understanding business logic
If you want to refactor the code and write better, first you must understand the business logic of code/classes before starting rewrite to the code.
What does this piece of code,
What is the responsibility of it,
Serve for what behind to hook,
How many places call this class/method,
What is the current position of this code in a business flow,
Why do we need it,
What is business logic,
What is END PURPOSE of this code,
What kind of functionality exists in the method(To better see it you can extract the part of the code, but just doing that doesn’t mean I’ve refactored),
How is the work,
…
….
Read the method read read again. As I said don’t dive too into the code. Read, debug, run tests, and understand the purpose of the method. Code can’t run away from you.
Without understanding why a code works the way it does, You will never be able to refactor code, you will just change a few variable names maybe modify the method name, or delete one redundant if/foreach, and put everything in the utility class, and be happy haa!!!
Sorry, but it is not refactoring, First strive to understand the purpose of the method deeply.
5-First don't touch the method, write the tests
First, write tests. If the tests already exist then again check, maybe something is missing, or maybe there needs to be additional test cases. Before smashing the code, test scenarios should ensure that the code is working correctly. Without tests refactoring is useless.
Look at tests carefully it will help you a lot while you refactor if you understand the tests.
6) Don’t Try to finish all at one time - Give it time
The code can’t run away. You don’t need to finish it all at one time, It is okay if need more time. You understand a little bit and you refactor a little bit. You can leave it like that for now. Next sprint or next month when you need to touch this method again Bingoo you are already familiar with this method. Now read again, refactor again, and make it better.
Thus, you will learn the business logic and structure of the project better in each sprint. You will feel much more informed. You will refactor faster and faster because each spring you know the business logic better, and you will start to enjoy writing code.
You can’t make perfect the method all at once, you can make it better over time by improving it a little bit each sprint. Because you get to know the code better with each sprint.
7)Don’t make huge refactoring
Please, please don’t do that. I know, You’re dying to fix the method on the next side, I know another class calls you to come, come, come to refactor me. You wish you could give a hand to another method as well, look at other classes this and next, next…
When you make huge refactoring it will grow and grow more. You can’t understand deeply 8–10 methods/classes in one sprint.
Moreover, huge refactoring should wait in PR for a long time and other teammates might work for the same component where you already refactored and they will wait for your PR merge because they don’t want huge conflict and unnecessary work and you blocked them Oops Now, extra time pleasure, Omg and so many comments, huge conflicts, You have to rollback something or you need to put in extra thing, maybe you broke somewhere, it will stay in PR for a long time but looks like you’re already tired of refactoring. You already regret touching the code. You just want it to be over when you close your eyes and open your eyes. Or maybe you should roll back all and save yourself from this stress but, but you spent so much time on it, what do you have to do ?? Maybe you will be scared of refactoring next time.
Be patient, don’t do that, just try to make small refactoring of one or two methods/classes.
Leave other things for next spring. Code can’t run away from you.
8- Refactoring should be consistently
You refactored the method now all done?? Nobody should touch it again, aren’t they? No, no no,
Refactoring should be consistent.
Scenario: You are writing code and you need the existing X method, Most probably you need to put an innocent “If” condition or small changes and use the X method. But It has changed so much over time that it is impossible to touch it anymore. The slightest change will cause the system to malfunction and the same in tests.
And now you understand that “If” wasn’t innocent. So when you need to touch a method, read it and try to understand, and if you feel it needs refactoring, go smash the method, clean it, and refactor it.
But maybe you need to touch the 10–20 method, shall you refactor all, but you don’t have much time? Then leave other methods for the next sprint for now. It is okay, the code will not run.
9-Do not expect a separate Jira ticket for refactoring
Hey boss, please don’t assign to me new tasks for the next 2 months. I will refactor the code, can I? My boss is so visionless they don’t understand refactoring!! Go just blame managers again …
Refactoring is a hidden default duty added to Jira tickets. (Y.B.)
Do not wait for separate tasks for refactoring. You should refactor regularly on each task.
10-) Arguments/ Parameters (It is a KEY)
You made refactoring ?? really !!!! Come on Yusuf look at the method, This method still has 12 parameters, Let’s be honest you just throw something in the utility class like everything, change some variable's names, and satisfy yourself.
Look I don’t tell you your aim should be to reduce the parameters. this should be a CONSEQUENCE.
If after all refactoring and argument size are the same then it means you need to learn more about clean code, refactoring, tests, and principles.
Go read more books,
Listen to boring Venkat speeches again, don't forget Uncle Bob, conferences…
and come to code back and refactor again and again and again.
If you strive to grow your knowledge you will see the end of refactoring in the method some of the parameters will appear redundant in your eyes. And Bingoo you catch it now you can see everything more clearly and you know these 3 parameters are redundant go delete it solider. You are a real soldier. It is okay if you left 9 parameters. Leave them for now, next time, and next time will be better to delete one or two and you will see how the method looks lovely. How parameters are decreasing one by one. Go slow, go strong.
No worries, leave the rest parameters for next time.
Warning: This is just a Joke Venkat’s speeches are known for their humor and often elicit laughter 😆😹 😂
11-)Last checks- Don’t forget to come back with tests and refactor it
There is no need to put extra words. Go to check tests, if they need refactoring as well, then just do it.
Be careful, without clean tests refactoring is just torture
12-) Don’t Forgot version control system(Git)- Update your branch frequently
Don’t leave everything to the last commit. In time, the conflict will grow. Go step by step and commit to each step. So when you’re stuck, you can roll back and start one step behind. You don’t need to go back to the top all the time.
Update your branch frequently don’t leave conflicts end of the sprint, See the change made, maybe the things you refactored have already been deleted.
And never forgot: Code can’t ru…
