Refactoring

I l @ ve RuBoard

Are you sure that what you programmed yesterday , last week, or last month was written the best possible way? Has this code since become redundant? If you agree that the best system is clean and uncluttered, then regular housecleaning will be required. Refactoring is the process of cleaning up the Web site. It is not just a programming task ”everyone on the team will need to participate.

This essential step can be easily worked into your daily routines: As soon as you finish a task, step back and review what you did. Ask yourself: "Was there a better, more efficient way to do this?"

Over time Web site components become obsolete and the design needs to be updated. You will need to look back not just to earlier today but to yesterday, last week, and last month. At the end of each iteration, look at the Web site and ask yourself the following questions:

• Are there multiple objects doing the same thing?

• Is there code for functionality that has since been removed?

• Have the directory structure and naming conventions been followed?

• Is the site still easy to navigate?

• Is there enough room for the site's content?

• Does this site communicate the original vision?

Once you have the answers, you may have a list of tasks to complete. These should be written up as stories and suggested at the beginning of the next iteration.

Getting customers to agree to refactoring stories is an important milestone in your relationship with them. The first time you tell a customer that you want to spend her hours making the code better, be ready for trust alarms to go off. "Why didn't you write good code in the first place?" "All the tests passed; you're just gold plating ."

Your first response might be to get very defensive. Don't. Explain that you wrote the code to make the test pass but now you want to make it better. Tell the customer what better means. If you can't, then you shouldn't be refactoring in the first place. In the end the customer makes the call.

I l @ ve RuBoard