Only Wear One Of Four Hats

KentBeck told me something very important one time. When you are coding you should only be wearing one of four different hats. Do things a little bit at a time and limit the source of errors. You run your unit tests before switching hats. More often than not to add new functionality you need to do a little refactoring. Separate the two functions don't do both at the same time, refactor then add.
At one point in the C3 project I had a collection of hats on my bookcase to remind me how important a habit this is to develop. --DonWells

We've gone Extreme, and are down to two hats now: interface or implementation. And Don is right ... it's very important.

Please clarify for me how you only wear two hats. Two hats seems too few. Are you saying that if you come to a class which requires refactoring and cleaning up for its own sake, as well as requiring new functionality, would you advocate doing both in a single step? What we were taught is when adding new functionality, it should almost be a drop-in. Refactoring is usually required first to make it so. We would consider this to be two steps: refactoring and new functionality. Would you advocate a single step? --JeanineDeGuzman

Not at all ... read on below ...

Put me in the puzzled camp as well. Changing the Interface for refactoring vs changing the interface for new functionality seems distinct. So why drop two of the four hats? --PeteMcBreen

We refactored the rule ... read on ...

It's a two-d matrix, of course. interface / implementation vs refactor / add.

The refactor / add dimension, however, is your overall purpose. The interface / implementation dimension is the immediate purpose for your typing at the moment.

The XP rule SitOnOneCard directs that you only have one overall purpose, pins the refactor / add dimension (and also the add one thing / add another thing).

That lets the hats refer only to your coding activity net of overall purpose.

A common strategic problem is to work on two cards at once. A common tactical problem in the heat of coding is to work on interface and implementation at once.

Don's formulation is good advice as phrased. We now break out the two dimensions. Sort of refactored the rule.

I think some [/all?] of the places above where the verb "to refactor" is used, it may be an instance of an outdated term, where the later decision was to use the word "design" instead. --MikeSchwartz

In this case refactor is correct. That has to do with the ExtremeValues where it was decided that design was a more general term for refactor. Refactoring is often how we do DesignInXp. --DonWells

Ooops, yeah, See also RefactorOrDesign. --MikeSchwartz

CategoryRefactoring

EditText of this page (last edited July 21, 2003)
FindPage by browsing or searching

This page mirrored in WikiPagesAboutRefactoring as of July 17, 2004