What Is Prefactoring
Pages: 1, 2, 3

Extreme Readability

The "Use the Client's Language" guideline suggests that the code that embodies business rules should be readable by the client (the person providing the specifications for a system). The rules should use the terminology of the client. The logical presentation of the code should match as closely as possible the flow as provided by the client. For example, a client might want to offer discounts for purchases over a particular amount. So the code could read:

    Percentage discount = 0.0;
    if (total_of_purchase() > PURCHASE_LIMIT)
        discount = PURCHASE_DISCOUNT;
    if (total_of_purchases_in_last_year() >
        PURCHASE_YEARLY_LIMIT)
        discount += ADDITONAL_YEARLY_DISCOUNT; 

With readable code, the client has the opportunity to review the business rules to check that they have been correctly translated. Changes in the rules become easier, as the client can mark up the actual code with the alterations.

Testing

The importance of testing has been re-accentuated by the Extreme Programming movement. The guideline "Plan for Testing" suggests exploring how you are going to test the system before you decide on the internal design. Starting with the use cases, you can develop outlines for tests that verify proper system operation. You may also develop misuse cases, which state the ways a user may unintentionally or intentionally abuse a system. For example, if you were creating a system to give discounts on purchases, a misuse case could be entering a discount greater than 100 percent or less than 0 percent.

Creating the tests and reviewing them with the client may help you discover any unclear, missing, or ambiguous requirements. For example, the tests for the discount misuse case are to enter values greater than 100% and less than 0% and see if they are rejected. Reviewing these tests with the client might reveal other rules, such as the sum of all discounts should not exceed a certain number. Clarifying the requirements before design always helps to reduce the amount of code changes.

Retrospectives

Part of the process of prefactoring is continually examining why you have needed to refactor your code or make other changes in your design. Performing a retrospective after each release may provide you ideas on design alternatives that may better fit your project. (see Norm Kerth's Retrospectives, or Project Retrospectives: A Handbook for more information). Designs that are more congruent to the underlying concepts can make it easier to implement the requirements for the next iteration.

The retrospective may also reveal new guidelines that you can employ in your development work.

Summary

Applying the experience embodied in the prefactoring guidelines may ease the development of your next programming project and reduce the need for refactoring.

Ken Pugh has extensive experience in the area of software analysis and design, both as a doer and as a teacher. He's a well-known, frequent conference speaker, and the author of Prefactoring, from O'Reilly.

---

Return to the O'Reilly Network