Like every programmer, I often come across code that isn’t quite right or just plain bad. Sometimes it’s my own, sometimes it’s not. It happens to every programmer though. You write some code in a hurry, maybe don’t quite understand the problem very well, or just learn a much better way to do something after the fact. The question though, is how to handle refactoring that code?
I sometimes have perfectionist tendencies so when I come across bad code it’s often tempting to dive in and start refactoring. It feels great to take some ugly code and turn it into a work of art! While often times this is not a problem, especially if it’s a small refactor, I often find that I have blind spots that prevent me realizing what I’m getting myself in for.
Problems With Refactoring
Here are a couple problems I’ve noticed when undertaking large refactorings.
Not fully understanding why the previous programmer did what they did.
Often times programmers think it’s going to be easy to refactor code because they can’t see the full picture and don’t understand the challenges the previous programmer faced or thought process for solving it. They don’t know the meetings that took place to discuss the best solution or the alterantive approaches that were tried and failed.
It may take longer than expected or lack of time.
I’m a severe underestimator of the time it takes to finish a project or feature and I’ve found most programmers are the same. With that in mind it can be dangerous for a project when a programmer jumps into a big refactor with limited time and an underestimation of the required time.
Nowadays when I come across some shoddy code, if it’s not quick and simple, I try to be diligent about noting it somewhere, whether in a ticket tracking system or as a simple “TODO” in the code, and then come back at a later time. This keeps me from wasting time that I don’t have and prevents me from forgetting about it and letting bad code go forever.
We all write shoddy code so let’s make better. Just don’t do it blindly.