Re: refactoring when using CVS

[Tom Plunket]

Greg A. Woods wrote:

> Hmmm... but in an eXtreme Pogramming environment you won't be checking
> things into CVS until they bloody well work now will you!

Huh?  What part of "continuous integration" don't you understand?

For those who are unclear on the concept, "integration" implies
"integrating" with the codebase.  "Continuous integration"
therefore implies that you check your code in as soon as it
works.  "Works" does not mean "complete functioning" but rather
"current suite of tests pass."

Btw- in XP, it's working as soon as all tests pass.  That's
pretty much right away.  The XP zealots say "continuous" actually
means every 2-3 hours (and you check out every morning,
discarding uncommitted changes), although I tend to something a
little quicker than that.  I admit, though, that I'm not doing
XP, just some of its practices which help me in my solo work.

> I.e. refactor early, get it right, then check it in.

"Refactor mercilessly" does not mean "refactor for a little while
then stop."

> When doing XP you'll probably only want to be using something like CVS
> to maintain already developed code, not to track every daily nuance of
> your initial development effort on new code.

Strange, that's exactly how I use it.

Then again, I'm not renaming files like crazy- there's no reason
to as far as I can tell.  The classes (C++ development) don't
need to change name, most of my "refactoring" work ends up
splitting out functionality and creating new files.  Haven't had
a whole lot of problem doing that in CVS but maybe I just haven't
used it enough.

> XP has other ways to deal with change management during the 
> initial authoring of a program or some component of a larger 
> program -- indeed that's one of the main reasons for doing things 
> the XP way in the first place!

Like what?  As I understand it, one uses source control.  If CVS
doesn't work then don't use it, but if it does, why can't I?

The XP way, again, does not EVER suggest that you use some of the
practices sometimes and then move on to other practices.  You do
all of the practices always, or you ain't doin' XP.

> If you're using XP methods for maintenance of existing code then 
> you'd damn well better skip the refactoring step or you'll only 
> cause yourself (and your partner) some MAJOR headaches! 
> (regardless of what the refactoring may or may not affect the 
> file structure!)

If you are using XP then you aren't "shutting off" parts of it.
If you don't want to do XP, then that's fine.

Here's a hint- know something about which you spew before
spewing, ok?

I came to this list because I don't know jack-all about CVS
beyond very base configuration.  That's why I'm here.  Someone
wants to say CVS and XP don't mix, that's fine, but don't expect
that the people who actually know something about XP to sit
quiet.

> Refactoring code during mainenance must only be done with extreme 
> care and a good deal of planning.  XP or no XP.  CVS or no CVS.

If you're using XP then you don't need to take much care in
anything because your software is properly designed in the first
place.

In fact, I don't think I've written a piece of code in the last
five years that I wasn't able to go in and considerably screw
with without fear.  These days I don't even execute the code on
real data before releasing it- the tests pass, it's good to go.
(Yes, this is real software being used heavily by real users in a
real company with an really enormous budget.)

-tom!