Sponsored Link •
|
Summary
Prefactoring has generated some discussion among developers. Some developers have formed opinions about it based upon the editorial summary in Amazon. Unforunately that summary was not approved by me and was full of marketing hype that did not represent prefactoring. This entry hopes to clarify the issues.
Advertisement
|
Prefactoring evolved from a Birds of a Feather session at a Software Development conference in Washington, D.C. Martin Fowler, Ron Jeffries, myself, and several others discussed why software came to need refactoring and practices that might be used to lessen that need. Spurred by that discussion, I compiled a set of guidelines for creating software and entitled it Prefactoring.
Refactoring, according to Martin Fowler, is a controlled technique for improving the design of an existing code base. It does this by applying a series of particular code transformations, each of which are called refactorings.. Code smells suggest refactoring,
Prefactoring guidelines emphasize things to think about before you start coding. Refactorings are code transformations performed after you have created code.
The prefactoring guidelines encompass some that are directly related to code transformations and others that are not. A commonly used refactoring is Extract Method. The Separate Policy from Implementation prefactoring guideline suggests organizing methods into ones that perform implementation (e.g. totaling a customers purchases) and ones that perform policy (e.g. giving the customer a discount based on total purchases). If you think about this guideline as you develop the code, you may find yourself separating many methods, and therefore requiring fewer Extract Methods. Separating policy from implementation is not an operation you can perform mechanically. Its something that you have to do intentionally. Coding with intention makes your code start with less smells.
Other prefactoring guidelines do not deal with code transformations. The Easiest Code to Debug is That Which is Not Written.guideline suggests that you use Google as a development tool. Before even writing a single line of code, google to see if the feature you are about to create exists in either open source or commercially available software. If it is, check it out. You may get away with not having to write a single line of code. Even if the software doesnt work out, youll have an opportunity to see how others have approached a solution. Developing software is not just about writing code; its about delivering solutions, regardless of how they are created.
There is no big design up front in prefactoring. The Think About the Big Picture. guideline is not about big design. It suggests that you spend a little bit of time investigating the environment in which you are going to create your software. The environment (e.g. a corporate infrastructure, J2EE, or web services) may provide numerous services (e.g. security or error handling) that you dont need to develop or it may suggest ways for structuring your code to fit into the framework.
Following the prefactoring guidelines does not mean you dont refactor your code. The guidelines can help keep the smells out. . But when code starts to smell, refactor it. As you go through development, you gain more knowledge about the total project, which can generate new ideas. Performing a retrospective after every release, as one guideline states, can help direct this generation of new ideas.
Agility is about delivering working software to the customer. Iterative and incremental development and customer communication, as shown in the example in the book, are key principles to enable that delivery. You can use multiple tools to achieve the goal refactoring performing transformations on created code is one tool, prefactoring thinking about things before coding is another.
Have an opinion? Readers have already posted 23 comments about this weblog entry. Why not add yours?
If you'd like to be notified whenever Ken Pugh adds a new entry to his weblog, subscribe to his RSS feed.
Ken Pugh of Pugh-Killeen Associates (www.pughkilleen.com) consults, trains, and mentors on technology topics ranging from Object-Oriented Design to Linux/Unix to the system development process. He has served clients from London to Sydney. When not computing, he enjoys snowboarding, windsurfing, biking, and hiking the Appalachian Trail. |
Sponsored Links
|