Try to refactor your code whenever you get time.
This is a very small post(actually my linkedin post) but very helpful.
If you don't have the habbit of refactoring your code, try now, this is going to be the best experience and learning for you.
How code refactoring would help???
You will realize that there are some pieces in your code which are not at all being used. Now you can delete them. This gives immense pleasure 😅.
You can apply your newly learned things. For me, I was never confident in object destructuring in javascript but in refactoring the code, I applied my learning and became more confident like giving initial value, renaming in destructing.
As your code gets better and better and now that you have gone through it many times, you can now explain it to anybody about your project and how you did it. Most of the times, we are not able to explain our code just bcoz we left it after we realized that it's doing the required job and never cared to refactor it.
Doesn't matter if project is big or small, you need to refactor it now.
Let me know your thoughts in the comments.
That's it, have a good day dev 😊.
Top comments (19)
Be careful though, always go refactor with baby steps. Verify after every small change that the code is still working as it should. Automated tests are incredibly useful for this.
If you try to make multiple changes at once, it's easier to lose sight of what could be affected. Also, the combination of multiple changes will result in an exponential number of issues that can be caused.
One of the best and easiest way to refactor is to rename and move things. Learn the hotkey of your IDE to rename variables, classes, functions and files. It will make the code much more understandable for the next developer (or yourself after a few weeks)
I usually write a terrible hacky mega-function that contains basically the entire application, validate that it works, write tests, and then refactor it to be reasonable, relying on the tests to do most of the work of verifying that it's still behaving.
And for the love of god write tests. Having tests is the safest way to go around this, if your refactor breaks something your tests will catch it.
Big fan of writing tests and these are a blessing for refactoring, but there are some considerations to make.
As always in IT, it's a trade-off. It's not "write tests" vs "don't write tests". It's about finding the balance between "effort" and "confidence" that's most fitting for the problem at hand.
Completely agree. Also it's nearly impossible still for me to change things and keep them still working. But that's the real learning I'm talking about, learning of your project's code and how it's working. The more you play the more you learn. :)
I had a professor that taught me a good thumb rule: You have 2 hats: the feature hat and the refactoring hat. You can't wear two hats at a time.
Refactoring means changing the factoring without changing features. Code refactoring comes into play once the feature is done :)
I beg to differ. It is paramount to create code which is as clean as possible when developing, but once it's merged it should be changed only via tests and small steps. Or you could just accept chaos and live with it.
Hi Alain! You are totally right... But my point of this post is to tell people to keep learning. You can try above points only on a small project or your side project. Obviously big projects require testing.
Code refactoring might generate some bugs but that's exactly the point of learning. I hope you understand my point now.
Have a good day :)
I understand and embrace it actually. But I felt like the post encouraged people to break things in general, instead of breaking their own things which is actually learning for me
Learn more about code refactoring: devopedia.org/code-refactoring
One of many good practices when done correctly.
Yeah... :)
Refactor before merging a feature. Too often we get something working and then immediately move on. We should dedicate a real amount of time, per feature, for reflection and refactoring.
Exactly!
Reminder to keep your commits clean during refactoring. Don't refactor in same commit as fix or feat. Well small refactor related to a fix can be acceptable.
I have found that working with gitmoji, or conventional commits, the level of clarity on your code increases. It also results in refactoring as you work to separate all of the unrelated changes.
Looks like a good practice . Will try for sure
:)