DEV Community

loading...
Cover image for Please refactor your code.

Please refactor your code.

harshvats2000 profile image HARSH VATS ・1 min read

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???

  1. 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 😅.

  2. 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.

  3. 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 😊.

Discussion (20)

pic
Editor guide
Collapse
dumazy profile image
Fré Dumazy

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)

Collapse
jaronsummers profile image
Jaron Summers

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.

Collapse
rvxlab profile image
RVxLab

Be careful though, always go refactor with baby steps.

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.

Collapse
dumazy profile image
Fré Dumazy

Big fan of writing tests and these are a blessing for refactoring, but there are some considerations to make.

  • Not all areas of the code are easy to test. UI is mostly harder to test than business logic, for example, and tends to change relatively fast, which requires updating the tests. In some cases, the effort vs confidence balance will be better with manual testing.
  • writing tests after a feature was made could be misleading (and boring also). The test would be written to validate the current state of things, instead of the requirement. There could always be a bug in the original code that hasn't been spotted, and you end up with a test that falsly says it's working fine.
  • To be able to test code, the code has to be written in a way that made it testable. Mostly this means having it "loosely coupled". Changing this during a refactor might lead you down a rabbit hole.
  • Writing tests is a practice that takes years to master. It's an investment in the long-run, one that might outlive the specific project or only give advantage after the deadline.

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.

Collapse
harshvats2000 profile image
HARSH VATS Author

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. :)

Collapse
mrlopis profile image
Joao L.

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.

Collapse
harshvats2000 profile image
HARSH VATS Author

Refactoring means changing the factoring without changing features. Code refactoring comes into play once the feature is done :)

Collapse
alaindet profile image
Alain D'Ettorre • Edited

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.

Collapse
harshvats2000 profile image
HARSH VATS Author

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 :)

Collapse
alaindet profile image
Alain D'Ettorre

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

Collapse
arvindpdmn profile image
Arvind Padmanabhan

Learn more about code refactoring: devopedia.org/code-refactoring

Collapse
sebring profile image
J. G. Sebring

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.

Collapse
jessekphillips profile image
Jesse Phillips

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.

Collapse
andrewbaisden profile image
Andrew Baisden

One of many good practices when done correctly.

Collapse
harshvats2000 profile image
HARSH VATS Author

Yeah... :)

Collapse
anurag0s1 profile image
Anurag • Edited

Looks like a good practice . Will try for sure

Collapse
harshvats2000 profile image
Collapse
jackmellis profile image
Jack

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.

Collapse
harshvats2000 profile image
Collapse
ageekdev profile image
🅰️ GEEK

Refactoring is fun feeling accomplished everyday, but often leads to premature optimization and illusional productivity.