Refactoring is an activity that needs to be done on a continual basis. Just as a team shoud do Continuous Process Improvement, there should be continual efforts for design improvement through refactoring. There are many different refactorings that you might consider doing to clean up some questionable design aspects, or bad code smells. Maring Fowler details many of these in his book, Refactoring: Improving the Design of Existing Code. The refactorings described in his book, and other new ones are listed here. Fowler also has a portal for information on refactoring at www.refactoring.com.

Refactoring intends to makes changes to the internal design of software without effecting any of the observable behavior of the system. You will undertake a refactoring to make the software easier to understand and to modify, not to add new behavior as a result of the refactoring. The addition of new behavior, now possibly facilitated by the refactoring, can be done after you have verified that the refactored system is behaving exactly like the original system. To accomplish this, you will need to follow a step-by-step process of small incremental changes that move you from the current design to the refactored design. Along the way, you will have parts of both old and new designs in place. At multiple points, you will want to run a full suite of tests to ensure that the system still behaves as it originally did.

For this exercise, list all of the steps that you would need to perform to complete a Replace Conditional with Polymorphism refactoring. Use this Word file for completing the exercise. Each step should be a small incremental change. The description of each step should be no more than a sentence or two. Indicate at what points you will do a system test to ensure that none of the behavior has changed. Make sure that after the last step the system will have evolved completely from the original design to the refactored design. There should be no vestiges of the original design left in the system that are not part of the refactored design.

For the purposes of this exercise, assume that no tests currently exist for this part of the system. It is often the case that an engineer will need to refactor legacy code that is not already under test ( shockingly, even professional developers don't always follow standard practice). In these cases, you will need to write tests to characterize the current behavior of the system. These are called "characterization tests," naturally. This will create a test harness that will allow you to safely refactor the code, rerunning the tests each time you make a change to insure that nothing has broken.

Complete this exercise individually by the due date. There will be a class discussion of the steps to perform this refactoring immediately after the dropbox closes.