Refactoring in the Small

When I started writing programs I was given small problems to solve. I was learning by programming in the small. How could it be any other way?

Programming in the large requires skills that you can’t learn from programming in the small. For example, there is no need for me to come up with an error handling strategy when I’m writing a command line utility implemented by one or two classes. But I don’t want to use any kind of framework that doesn’t have an error handling strategy.

What I’ve noticed is that the skills that I learn while programming in the small are still valuable when programming in the large.

Try something similar with refactoring. Begin by learning how to effortlessly refactor in the small. Learn how to create a Composed Method by applying Extract Method a few times. If things go wrong, just apply Inline Method and try an alternate breakdown. Maybe you need to apply Encapsulate Field prior to Extract Method. Perhaps your newly extracted method is not sufficiently general so go ahead—apply Parameterize Method. Nice.

Learn the names of the refactorings. Use your programmer honed abstraction abilities. Start to think of a refactoring task as a sequence of refactorings rather than arbitrary text manipulation. The skills you learn while refactoring in the small are skills that you will need to refactor in the large.

Suppose you need to restructure some complex procedural code, full of intertwined conditional logic, and plan to use object composition to manage variation. Are you thinking of the Strategy design pattern? Now you’re refactoring in the large. Thinking about the overall restructuring task dominates the refactorings. So you must learn to effortlessly apply refactorings or you’ll mess up your restructuring.

So what is refactoring in the small? Is it making changes in only a single class? Nah—too simplistic. What if the class is one of your central classes? What if it has that Large Class smell? Besides, once you get good at it, a straightforward refactoring may affect many classes.

For me, I’m refactoring in the small when the refactorings take place in a single programmer episode. If things go wrong it’s easy for me to back out. I can’t try anything too ambitious. Programming episodes are where I learn to apply refactorings.

So c’mon folks. Start with baby steps. Practice. Learn. I want you to become a refactoring in the small ninja before I catch any of you restructuring your code.

Leave a comment

Your comment