Refactoring

for RuBoard

No discussion on evolutionary software development would be complete without at least mentioning the practice of refactoring improving the structure of existing software without changing its functionality. Refactoring changes the internal structure of software to make it easier to understand and cheaper to modify without altering its observable behavior. ^[6]

^[6] Fowler, Martin. Refactoring: Improving the Design of Existing Code . Reading, MA: Addison-Wesley, 1999. Page 53.

The term refactoring first surfaced in SmallTalk circles, but is now bantered about in nearly every programming discipline and language. Early proponents of refactoring included Ward Cunningham, Kent Beck, Ralph Johnson, Bill Opdyke, Martin Fowler, and many others. To be sure, I suspect many expert developers were refactoring before the term ever existed. It is a natural outgrowth of experience in the trenches. You refactor to save yourself trouble down the road and because you don't like to solve the same problem twice. Seasoned developers knew this before the term refactoring existed.

Martin Fowler's seminal work on the subject, Refactoring: Improving the Design of Existing Code , adeptly articulates and catalogs what has become its own software engineering discipline. Refactoring is an important skill. As important, in fact, as just about anything else in the programmer's toolbox. Understanding it and learning to ably refactor existing code is as essential as any other talent you will acquire as a developer.

The key to keeping code readable and modifiable is constant refactoring. Expert developers tend to be a bit compulsive about refactoring, and this is a good thing. Cleaning up messes ( especially someone else's) is rarely anyone 's favorite job, so programmers who care enough about quality to do so on their own are a special breed indeed.

You can make many changes to software without changing its external behavior, but only those that make it easier to understand or cheaper to modify qualify as refactoring. This means that performance tuning, often cited as a type of refactoring, really isn't, because it amounts to changing the observable behavior of the system.

Note that refactoring isn't blind code modification either. It's not change for the sake of change. To work consistently over the course of a project, refactoring must be done systematically. Otherwise, you risk digging your own grave, making so many disorganized and untested changes that you break the software beyond repair. As I mentioned earlier, the development cycle has to be change-test, change-test, change-test.

The two key components of refactoring are small changes and exhaustive testing. ^[7] You cannot begin to refactor an application without a solid suite of tests. To do so is to invite disaster. If you can't verify that your change, no matter how small, did not break something, how can you with confidence proceed to the next change? You can't. And that's why you need to construct comprehensive tests before reworking code you may or may not understand well. ^[8]

^[7] Ibid. Pages 1213.

^[8] Beck, Kent. Extreme Programming Explained: Embrace Change . Reading, MA: Addison- Wesley, 2000. Page 66.

Testing is a subject of its own chapter in this book, so I won't go into it much here except to say that all tests should be automated and should check their own results. That is, you shouldn't check your work by hand; you should construct tests in the program code itself. Your code should expose test methods that can be called to quickly check its accuracy. Once you refactor an existing piece of code, testing it should be as easy as clicking a button. Tests that are difficult to run or less than foolproof tend not to get run. If a test is difficult to run, developers are likely to skip it during crunch time. If it's not foolproof, it won't be trusted, and running it will eventually begin to seem like a waste of time.

The single most common type of refactoring is the removal of duplication from a system. All of software engineering boils down to just this: representing each piece of logic required by the user in exactly one place. Hunt and Thomas ^[9] refer to this as the DRY (Do not Repeat Yourself) principle , and it applies across the broad spectrum of computer engineering. Quite often, refactoring concerns itself with eliminating duplication from a system so that each logical element is represented once and only once within the systemso that it complies with the DRY principle. This is not unlike database normalization. Think of it as "code normalization."

^[9] Hunt, Andrew, and David Thomas. The Programmatic Programmer . Reading, MA: Addison-Wesley, 1999. Page 27.

Duplication creeps into a project in a number of ways. The chief way is through impatience. A developer looks at a problem, sees that it's similar to one he solved yesterday, grabs the code he wrote yesterday , pastes it into a new method, and changes it a little. This saves time now, but will likely cost him later. Sometimes supposed shortcuts aren't shortcuts at all. Sometimes they lead to long delays. Don't take the poisoned apple of easy duplication. And if you come across it in your code, refactor it on sight.

for RuBoard