It’s Red, Green, Refactor. That means after changing the code, you perform some refactoring to make things get to their best form. If folks don’t do that relentlessly then the amount of refactoring you could do would be larger than you could be expected to do.
Here are a few ways to choose how much refactoring you ought to do. Do as much as you can and eventually your software will need less and things will be easier and faster.
- The reflected light – imagine all code you’ve changed being subject to refactoring, this includes anything immediately touching the code you’ve changed Using the above picture of a spotlight, it’s all the bright stuff. In order to see where to make a change, you probably focus your attention on more than just the lines you’ve changed.
- The shadow – as a second degree refactoring approach, the fuzzy grey area, which is not quite lit, but has come into view, would be considered too. This allows you to spread the radius of your improvement a bit wider, but doesn’t commit you to changing the world.
- Inverse square law – perhaps another approach is to look at distance – not physical so much as cognitive – between the thing you’re changing and the rest of the system. If something is very related, then with the inverse square law, it would be very subject to refactoring. If something’s quite related, it’s still strongly subject. If it’s only a little related, then the inverse square law starts to lose pull on it, and drops off more rapidly the further way the relationship gets.
- Fix according to the knowledge path – if you imagine your journey of discovery to make the software change, a path through your system, then you could pick up litter you found along the way. You’ve just experience the pain of working with that knowledge/detail and it’s fresh in your mind. Make it a bit better.
Each of the above metaphors is a way to cut the cake on this. You have to find what works for you. My experience is that the last one is quite effective. The roads most travelled in the system are the ones which slow you down the most. As you get them into decent shape, then other techniques, like the reflected light one, become more appropriate.
Whatever happens, take an honest approach to refactoring. Don’t overpolish, but don’t leave croquet hoops in the lawn for innocent people to trip over.