Article Preview
Buy Now
FEATURE
Refactoring REALbasic Code
Improving the Design of Existing Code
Issue: 4.5 (May/June 2006)
Author: Joe Strout
Author Bio: For the first time ever in these pages, Joe Strout is
Article Description: No description available.
Article Length (in bytes): 15,183
Starting Page Number: 31
Article Number: 4510
Related Link(s): None
Excerpt of article text...
Conventional wisdom and experience say that you design your code first, and then you actually write the code. This up-front design is important, since if you get it wrong, your code will end up an unusable mess, and you'll be forced to throw it out and start over.
Within the last decade, this conventional wisdom has been turned on its head. Software engineers now routinely change the design of existing code, through a systematic process known as
refactoring . Refactoring is more than just another tool in your programming toolbox; it fundamentally changes the way you approach software development. This article will show you how to do it, and what it means for your own work.What is refactoring?
The term "refactoring" is used in two ways. In the generic sense, refactoring is the process of improving the design of existing code. Refactoring is simply making changes to the architecture of your software, without affecting its behavior.
In the more specific sense, a "refactoring" is a particular
way of changing the code. The canonical book on the topic (Refactoring by Martin Fowler) details dozens of specific refactorings, and gives each one a name so that we have a common vocabulary for speaking about them. Some of them are quite simple, like "Rename Method" and "Replace Exception with Test." Others are more complex, like "Extract Method" or "Collapse Hierarchy."Each refactoring can be broken down into a set of step-by-step instructions, like a recipe. Unlike a recipe, you can actually pause after each step and test the final result -- that is, you can run your program and make sure you haven't changed its behavior. Then, with that assurance in hand, you can proceed to the next step, until the full refactoring is complete. Many of the more complex refactorings use simpler ones among their steps. Having clearly defined, verifiable steps makes refactoring a bit mechanical -- yet deeply satisfying, because you'll see your code growing cleaner before your very eyes.
...End of Excerpt. Please purchase the magazine to read the full article.