How to refactor a code marked as "It's Working, NEVER TOUCH!!"

Have you ever been tasked with refactoring a code marked as: "It's magically working. DON'T EVER TOUCH IT!!" 😅

If you've been working in our field for a while, you most likely came across this kind of ugly problem.

There's this function/service in your codebase that is probably 1000+ lines of code, and it's gottten so messy that adding any new feature/change to it will take HUGE time & efforts.

And this is not something that you will only see in legacy codebases, or in projects that were built by "unprofessional" companies. This is something that could have been written by you or me!! 😁

And that's actually normal. Because many times, when building a new feature, we are required to ship something working ASAP. Cleaning can come later.

However, as days go by, additional requirements are added to it, fixes here, patches there, ...etc.

Fast forward a few months, we have this monster in our codebase that on one dares to get close to😂😂

So our team makes the hard but very needed decision, that we need to refactor it. And the one to do the refactoring will be you 😱

So after getting over the shock, you will think about how do you do that??

The first step should always be sitting there & reading the code slowly several times while taking notes & diagrams about its structure & flow, until you feel like you have enough understanding about it.

Now here comes the funny part. Refactoring the code.

There are 2 main approaches that you can follow here:

1- You make modifications and changes to the code immediately. Cleaning things, moving things, re-writting things, commenting on things, ...etc. And this should work in most cases. But what I don't like about this approach is: It's hard to make big changes here, you'll mostly just refactor small pieces, but not the whole "layout".

So here comes the 2nd approach: Starting from scratch... 🙂

Now hold on a minute before you jump on me, allow me explain myself 😅

You won't literally start from scratch, what you will be doing is this: Use the knowledge you gained when studying the old codebase to build a better more suitable general structure that can still satisfy the requirements, using the smaller pieces of the old codebase.

And by "knowledge you gained" I mean: The edge cases, which parts are the most complex, almost duplicated logic,...etc. Essentially anything that weren't apparent to you when you were initially building this, but appeared later.

And as I said, many of the smaller parts will probably remain the same, so you can just copy-paste them.

Although on the surface, this way might appear like it takes more time than the 1st approach, but many times, it's the exact opposite!! And that's at least the case for me.

So maybe next time you want to refactor something, try to see if this approach works better for you too.

And that's it for today folks Leave a like if you found this helpful 👍

And have a nice day 👋