670 S '05
Lecture 1
Lecture 2
Lecture 3
Lecture 4
Lecture 5
Lecture 6
Lecture 7
Lecture 8
Lecture 9
Lecture 10
Lecture 11
Lecture 12
Lecture 13

Lecture 13: Refactoring

Code gets Bad! Don't Live with it, Fix it!

Code easily gets out of hand. The goal is then to stop adding functonality, fixing bugs, and subtracting old functionality. Instead, you re-consider your design, eliminate duplications, and focus on creating a single point of control for each current functionality. For every change, you run the test suite. It is critical that your changes do not affect the test suite. If you "accidentally" fix a bug, make sure you take a note and test it properly.

Setting Goals

Refactoring with a goal in mind is the best thing. It helps you find the bad spots in the code that might get in your way. So imagine that your "Carcassonne boss"
  • adds the method my-color to turn<%> so that a player program can determine the color of its followers;
  • adds an observer call-back sign-up (of color and name) so that observers find out who else is playing;
  • changes the distribution of tiles so that it corresponds to those found in "paper versions" of Carcassonne.


  • Martin Fowler. Refactoring. Improving the Design of Existing Code. Addison-Wesley. 2002.

last updated on Tue Jun 9 22:03:19 EDT 2009generated with PLT Scheme