info-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: refactoring when using CVS


From: Greg A. Woods
Subject: Re: refactoring when using CVS
Date: Thu, 21 Feb 2002 22:32:40 -0500 (EST)

[ On Thursday, February 21, 2002 at 16:57:53 (-0800), Tom Plunket wrote: ]
> Subject: Re: refactoring when using CVS
>
> 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."

I think you don't understand the concept of change sets.  What you're
talking about is what CVS already makes very easy.  "cvs update" early
and often and "cvs commit" every working change set!

What part of my explanation of "works" didn't you understand?

Perhaps you should review a few thousand commit messages from one or
more of the *BSD CVS trees to get a better feel for what I'm talking
about.

> 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.

No, you're not doing XP at all, as you'll admit in even more detail
below.  You're just working with code in the way CVS already makes very
easy.

Of course Aegis is even better with XP than CVS because of the two-phase
commit which helps with the "Only one pair integrates code at a time"
rule; and also with the ability to enforce and run test modules for
every commit (which obviously helps with the "All code must have unit
tests" and "All code must pass all unit tests before it can be released"
rules).

> > I.e. refactor early, get it right, then check it in.
> 
> "Refactor mercilessly" does not mean "refactor for a little while
> then stop."

Indeed, and refactoring in the XP way doesn't occur across the
development of multiple change sets, but only within the development of
one change set and thus the integration of refactored code won't
distrupt development.  XP is also more about refactoring at the design
level than the implementation, i.e. as opposed to something like in
Smalltalk where refactoring is more at the implementation level.
"Refactor" is one of those buzzwords often over- and miss-used in our
industry today.

Then there is this perhaps most important, and unfortunately least
stated, rule of XP:

        Fix XP when it breaks.

> 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?

Strictly speaking if you follow the XP practices to the tee (including
the rule to "Fix XP when it breaks"!) then you don't need any change
management tools at all.  You integrate your changes often (every time
they work), your changes are small, and only one pair integrates at a
time.  You don't even need a bloody computer to do XP -- you could have
all the typing, compiling, and testing done by the QA team!  ;-)

> 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.

exactly my point about you not doing XP.....   :-)

Of course there's still "Fix XP when it breaks".....  ;-)

> 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.

The day I believe that is the day I'll buy that ocean front property my
buddy in Saskatchewan (or my other buddy in Utah for your 'Mericans ;-)
keeps trying to sell me!  ;-)

If you're using XP correctly then the development process never stops
because you can be bloody well certain that the customer is never going
to be satisfied with any final acceptance test -- there'll always be new
and changing requirements and thus always new and changing design and
ongoing development.  "Make many frequent small releases"

-- 
                                                                Greg A. Woods

+1 416 218-0098;  <address@hidden>;  <address@hidden>;  <address@hidden>
Planix, Inc. <address@hidden>; VE3TCP; Secrets of the Weird <address@hidden>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]