Re: Re: Ambiguous Refactoring Solution

In article <8A89F8BA0CF8D14BB5E18AEEBBAC36EF6F8361022D@GVW1121EXC.americas.hpqcorp.net>,
    "Donaldson, John (GEO)" <[email protected]>  writes:

> I'm a little bit worried about this direction. I mean, in the cycle
> red-green -refactor, we have no motive for the refactoring, other than
> some nebulous conc ept of code goodness. So, if you see a class that is
> too big, and you have some
> time to spend on improving your code base - then why not?

We're talking legacy code here, not new development.

For legacy code, the rule of thumb should be
"if it ain't broke, don't fix it."

You only change legacy code in response to a need not because you feel
that the "goodness" isn't up to your yardstick, particularly when most
legacy code (all by Michael Feathers definition of legacy code) has no
tests covering it.
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
 <http://legalizeadulthood.wordpress.com/the-direct3d-graphics-pipeline/>

      Legalize Adulthood! <http://legalizeadulthood.wordpress.com>


------------------------------------

Yahoo! Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/refactoring/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/refactoring/join
    (Yahoo! ID required)

<*> To change settings via email:
    mailto:[email protected] 
    mailto:[email protected]

<*> To unsubscribe from this group, send an email to:
    [email protected]

<*> Your use of Yahoo! Groups is subject to:
    http://docs.yahoo.com/info/terms/