On Refactoring

Inspired by this post
I was recently handed the responsibility to maintain/fix the code of my officemate who has already left for greener pastures. Its my first day with the code so I did a 2-3 hour refactoring session with around 4k LOC.
I finished trudging through 1k LOC , and would probably be finished with the rest of the code if my team lead didn’t tell me to fix a critical bug (on the code I was refactoring).
Note One: I haven’t been told that the code was my responsibility but I have a sixth sense for things like this, so I faced the hurdle head on.
Note Two: Writing Unit tests before refactoring, trust me on this, You know that feeling you have before an operation, well that’s how you feel before and , while and after you are testing your code. No matter what you do you have that fear that maybe you didn’t do it right. So just write the test. Just do this for your sake.
I saw a few readily fixed errors around 10 and about 4 errors that took me awhile to understand and eventually fixed.
Around 2 hours after lunch we had a quick meeting because of the critical bug. The bug was a show stopper and at the meeting the code/functions/pages were formally given to me with a reminder:  We need the bugs fixed today.
luckily, some of the the bugs I have already fixed and my refactoring allowed me to easily zero in on the offending code. I was able to fix it in less than 30 minutes.
After two hours, my team lead comes to me and ask warily,
“When are you going to finish fixing the bug?”
“Its Already fixed”
“The bug? you sure?”
“yep”
The face of my team lead of disbelief/suspicion/slight admiration was priceless.
This was all due to refactoring!

Leave a Reply

Your email address will not be published. Required fields are marked *