Programs have two kinds of value: what they can do for you today and what they can do for you tomorrow. Most times when we are programming, we are focused on what we want the program to do today. Whether we are fixing a bug or adding a feature, we are making today’s program more valuable by making it more capable.
You can’t program long without realizing that what the system does today is only a part of the story. If you can get today’s work done today, but you do it in such a way that you can’t possibly get tomorrow’s work done tomorrow, then you lose. Notice, though, that you know what you need to do today, but you’re not quite sure about tomorrow. Maybe you’ll do this, maybe that, maybe something you haven’t imagined yet.
I know enough to do today’s work. I don’t know enough to do tomorrow’s. But if I only work for today, I won’t be able to work tomorrow at all.
Refactoring is one way out of the bind. When you find that yesterday’s decision doesn’t make sense today, you change the decision. Now you can do today’s work. Tomorrow, some of your understanding as of today will seem naive, so you’ll change that, too.
What is it that makes programs hard to work with? Four things I can think of as I am typing this are as follows:
Programs that are hard to read are hard to modify.
Programs that have duplicated logic are hard to modify.
Programs that require additional behavior that requires you to change running code are hard to modify.
Programs with complex conditional logic are hard to modify.
So, we want programs that are easy to read, that have all logic specified in one and only one place, that do not allow changes to endanger existing behavior, and that allow conditional logic to be expressed as simply as possible.
Refactoring is the process of taking a running program and adding to its value, not by changing its behavior but by giving it more of these qualities that enable us to continue developing at speed.