In all the years I have been developing software professionally I had to deal with a lot of code. At the beginning of the project, the code is mostly good but there comes a time in the life of every software project when the code base deteriorates. At some point in time, it can become a more or less unstructured pile of spaghetti code that is hard to maintain.
The reasons can be changing requirements, time constraints, arbitrary deadlines, scope creep, or the simple fact that you fully understand the requirements only after you have implemented the solution and spent a lot of time thinking about and discussing the problem you are solving.
But there is no time to throw everything away and start from scratch. (The "big rewrite" never works, trust me, I have tried it and failed)
It's time to refactor the monster I have created so we can continue to ship improvements and new features.
When I was a more junior engineer I wanted to refactor everything in one go. I started in one corner of the code and kept increasing the scope of what I wanted to clean up. At first, I thought I could do it in a week but on Thursday of that week, I knew it would take multiple weeks. After three weeks I felt like a tightrope artist where the end of the tightrope moved further away with each step I made. Going back seemed also scary because I had already gone so far out on that tightrope.
The more senior I get the shorter I want my tightropes to be. I do not want to have one enormous tightrope. I rather have a lot of tightropes, but each one only has a few steps, with solid ground in between.
When I read code now I make (mental and real) notes of what is confusing. When I have some time in a week I rename a variable, make the condition in an if more readable, pull some lines of code into a function, or encapsulate a dictionary or some variables into a class.
Everything that makes the code more readable helps. And I always remember:
You do not need to make it good, just better.
This works pretty well. Those small changes are quick to implement, the PRs are small and easy to review, and there is less chance of breaking things. I also do not need buy-in from anybody when I spend two hours improving our code base.
Over time these little changes add up. After a while I start to feel the compounding effect when implementing new features starts to become easier and faster again.
Comments