RE: [AM] Unfounded assertion

Jason,

> But new requirements can't be handled by refactoring, surely?

well... it depends

maybe we shouldn't pigeon-hole necessary changes as refactoring in that it
is only a first step.

That is, I always like to remind my teams that a "feature" should be easy to
add to the application. If it feels like you are jamming it in, then maybe
we need to alter the model/design.

So, you could alter the model (refactor), run the unit/acceptance tests to
ensure the app still works. Then, proceed to add the new feature.


So, maybe we can't call "adding new requirements" as "refactoring," but a
sense of fixing the model ahead of time to make the new feature "slip right
in" is how I like to work.

-- jon



> -----Original Message-----
> From: Jason Gorman [mailto:[email protected]]
> Sent: Monday, February 02, 2004 9:48 PM
> To: [email protected]
> Subject: 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
>
>
>

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