RE: [AM] Unfounded assertion

But new requirements can't be handled by refactoring, surely? If you have
new requirements then aren't you changing the behaviour of the system?
Refactoring requires you to preserve requirements at that moment in time,
surely.

Jason Gorman
http://www.objectmonkey.com 

-----Original Message-----
From: Jonathan Kern [mailto:[email protected]] 
Sent: 03 February 2004 02:45
To: [email protected]
Subject: RE: [AM] Unfounded assertion

Unfortunately, most refactoring is often thought of as low-level code fixes.
But, it should be more than that.

You should most definitely consider refactoring the problem domain when you
find out new requirements that "break" your model.

To not do this is to risk building up technical debt.

If a feature has to be "jammed" in to the object model, you are better off
refactoring.


-- jon



> -----Original Message-----
> From: Jason Gorman [mailto:[email protected]]
> Sent: Monday, February 02, 2004 7:17 PM
> To: [email protected]
> Subject: RE: [AM] Unfounded assertion
>
>
> Is refactoring "problem domain stuff"? I thought it was about 
> improving the technical design without changing what the system does. 
> Surely refactoring is "solution domain"?
>
> Jason Gorman
> http://www.objectmonkey.com
>
> -----Original Message-----
> From: Adrian Howard [mailto:[email protected]]
> Sent: 02 February 2004 15:10
> To: [email protected]
> Subject: Re: [AM] Unfounded assertion
>
>
> On Monday, February 2, 2004, at 11:00  am, Hubert Matthews wrote:
>
> > Adrian Howard wrote:
> >
> >> The better code review sessions I've been involved were more about 
> >> building the right system than they were about preventing mistakes.
> >> More "We can refactor that out into a new class"
> >> than "That will die horribly on edge case foo".
> >
> > This seems contradictory to me.  The first sentence implies an 
> > emphasis on the problem domain, but the second one seems to value 
> > technical matters rather than problem domain.  Can I ask you to 
> > clarify, please?
>
> Sorry, my poor communication skills again :-)
>
> I was trying to say that better code review sessions often focus more 
> on problem domain stuff (refactoring, etc.) than bugs. Good code 
> reviews as much, if not more,  about building the right system than 
> they are about spotting and preventing errors.
>
> Clarified?
>
> Adrian
>
> For more information about AM, visit the Agile Modeling Home Page at 
> www.agilemodeling.com
>
> For more information about AM, visit the Agile Modeling Home Page at 
> www.agilemodeling.com
>
>
>

For more information about AM, visit the Agile Modeling Home Page at
www.agilemodeling.com

For more information about AM, visit the Agile Modeling Home Page at www.agilemodeling.com
--^----------------------------------------------------------------
This email was sent to: [email protected]

EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrKDA.bWnbtk.Z2NtYS1h
Or send an email to: [email protected]

TOPICA - Start your own email discussion group. FREE!
http://www.topica.com/partner/tag02/create/index2.html
--^----------------------------------------------------------------