Refactoring is an extremely important part of the process of developing software. It’s what makes your code maintainable with the help of it’s equally important counterpart test suite. It is always good to go on refactoring mode after you made your tests green, but what if you miss it? What if you let it slip and they you have this snowball that will, before you notice, turn into an avalanche? How do you recover from it without compromising your process and your velocity?
It is important to spend time making your code more maintainable, it will make your velocity more consistent in the long run, but sometimes you can’t stop all the feature work at once to fix all the design problems you have, sometimes it is just too much, you have to start iterating. To do that you have to first define your pain clearly so you can get an idea of what you want.
Finding the problem might be a straightforward task, it may be right in your face screaming to be solved. But often times your team aquires the stockolm syndrome and then no one can see the problem anymore, that’s when a new member to the team is most helpful, the untrained eye can see the unseeable. Sometimes you know the problem is there and you just avoid dealing with it because your current code is “good enough”. Well, it is probably not good enough.
The problem with code is that there is always another way to do it, and while you think your way is better, your colleague might think otherwise, and you can always think of another way and another way that will seem better that your current solution. That said, you have to try and figure out what do you want to solve, finding the problem doesn’t necessarily mean that you know how you ideally want to solve it.
We’re talking about large design problems that have grown overtime, not a single messed up object or method that you can just extract out in a single coding session. If you feel like it is something you’re able to extract out in a short amount of time I say just do it. But if you feel like it is something that would take at least a few sessions you have to think about what steps you’re gonna take.
As I said, code can be written in several ways, so can your steps be defined. Think about your goal and figure out what is the smallest part you can enhance towards it. Do it. You will not have solved your problem, you will be closer but not quite. For example imagine you have a big object that has turned out into a method bucket that doesn’t quite make sense anymore, let’s say you want to extract each of the methods into it’s own class, extract one at a time then, and let your method bucket slowly turn into a meaningful object or even better, vanish.
The end of this story is very rewarding, this strategy allows you to do a major overhaul in your codebase with the costs of it amortized over several pieces of feature work. Try it out.
