Every day, our code is slightly better than it was the day before.
Entropy always wins. Eventually, chaos turns your beautifully imagined and well-designed code into a big mess of spaghetti.
At least, that’s the way it used to be, before refactoring.
Refactoring is the process of changing the
design of your code without changing its
behavior—what it does stays the same, but
how it does it changes. Refactorings are also
reversible; sometimes one form is better than another for certain
cases. Just as you can change the expression
x2 - 1 to
(x + 1)(x - 1) and back, you can
change the design of your code—and once you can do that, you can keep
entropy at bay.
Refactoring enables an approach to design I call reflective design. In addition to creating a design and coding it, you can now analyze the design of existing code and improve it. One of the best ways to identify improvements is with code smells: condensed nuggets of wisdom that help you identify common problems in design.
A code smell doesn’t necessarily mean there’s a problem with the design. It’s like a funky smell in the kitchen: it could indicate that it’s time to take out the garbage, or it could just mean that Uncle Gabriel is cooking with a particularly pungent cheese. Either way, when you smell something funny, take a closer look.
[Fowler 1999], writing with Kent Beck, has an excellent discussion of code smells. It’s well worth reading. Here are a summary of the smells I find most ...