Refactoring is a technique for changing the internal structure of the program without changing its external behavior. On the face of it, refactoring seems to involve a good amount of thinking, however, too much thinking could be detrimental as well.
Kent Beck suggested that one of the challenges of refactoring is succession which means how to divide the work into safe steps and how to order those steps. Moving too quickly on refactorings may result in getting burnt with unstable code. On the other hand, thinking too much and taking safe steps might slow down the process considerably.
As many of my pair programming partners could tell you, I have the annoying habit of saying “Stop thinking” during refactoring. I’ve always known this isn’t exactly what I meant, because I can’t mean it literally, but I’ve never had a better explanation of what I meant until now.
Kent explained the concept of 'horizontal and vertical refactoring'. Vertical refactoring would involve situations like moving the method or field up or down a call stack whereas, horizontal would involve doing a similar kind of refactoring across a bunch of siblings. According to Kent, one should not cross between either kinds when refactoring.
When you have multiple callers to refactor or multiple implementors to refactor, it’s time to begin paying attention to going back and forth between vertical and horizontal, keeping the two separate, and staying aware of how deep to push the vertical refactorings.
But doing this is not easy...
One thing which has been particularly helpful is index cards.
Keeping an index card next to my computer helps me stay focused. When I see the opportunity for a vertical refactoring in the midst of a horizontal phase (or vice versa) I jot the idea down on the card and get back to what I was doing. This allows me to efficiently finish one job before moving onto the next, while at the same time not losing any good ideas. At its best, this process feels like meditation, where you stay aware of your breath and don’t get caught in the spiral of your own thoughts.
J. B. Rainsberger agreed and mentioned,
Whatever you’re working on, when you want to focus, have a card and pen handy. When something pops into your head that you don’t absolutely have to do right freaking now, write it down in 5 words or less, then get back to what you were doing. It works wonders.
This is quite similar in principle to the narrow change approach suggested by Joshua Kerievsky. Here, focus is limited to a small number of change points at a time and then using this information the next narrow change or a parallel change can be picked up for refactoring.
Though refactoring involves thinking, however, keeping the focus and letting go the the temptation to go on a tangent is essential for healthy refactoring. As Kent put it,
Half way through my partner started getting good ideas about how to move some of the functionality to B. That’s when I told him to stop thinking. I don’t actually want him to stop thinking, I just wanted him to stay focused on what we were doing. There’s no sense pounding a piton in half way then stopping because you see where you want to pound the next one in.