[Zope3-dev] Progress

[Leonardo Rochael Almeida]

XP names the process of acquiring enlightenment about the problem domain
thru writing code a 'spike'.

A spike should require the least amount of overhead possible, because
you're only investigating the problem domain. In particular, I believe
one shouldn't have the burden of writing tests for a spike, but only
because spikes are throwaway code.

Since what we're trying to accomplish here is distributed-XP, I believe
it's ok to have spike code on a CVS branch, so that others can look and
comment and change. However, as others on this thread mentioned, code
without full test coverage shouldn't be merged into main development.
Once enlightenment has been achieved thru a spike, the development
proper should proceed the usual way: interfaces, tests, code; even if
the 'code' part consist mostly of cut and paste :-)

On Mon, 2002-03-04 at 07:32, Chris Withers wrote:
> Stephan Richter wrote:
> > 
> > At 07:28 AM 3/4/2002 +0000, Chris Withers wrote:
> > >Stephan Richter wrote:
> > > >
> > > > okay I just checked in my weekend+ net worth of coding. I checked the
> > > > branch this time and it compiles and runs the servers. For more I am not
> > > > guaranteeing, since there are no tests yet for the new functionality.
> > >
> > >D'oh! Write the tests first!
> > 
> > Easy said, if you have no clue about this stuff. 
> 
> Then you need to get the clues first so you can write tests...
> 
> > In situations where I am
> > able to do this, I WILL do it. After all, I also attended a sprint before!
> 
> Well, in situations where you can't do this, maybe you need to find out more about
> whatever it is you're trying to do so you can write tests first?
> 
> > > > - XML-RPC support
> > >
> > >...especially for something as major as that!
> > 
> > Well, this works only if you know the existing code base well. I had no
> > clue what I was doing until I was fairly deep into it. Then I found myself
> > rearranging ALL of ZoepPublication, 
> 
> Stephan, your enthusiam is amazing, and it's really cool to see so much work being done by
> someone outside of ZC, but surely changes as large as these sound should be saved for a
> sprint or at least involve lots of consultation with the other interested players like
> Shane and probably Jim?
> 
> > in which case all the tests would have
> > been intermingled.
> 
> Well, if you're making big chanegs then you need to adjust all other tests and code as you
> go along. Remember the XP maxim: "Refactor early, refactor often". My own addition is
> "refactor in small chunks". If you suddenly find yourself changing huge ammounts of code,
> you're trying to achieve to much in one go!
> 
> > All I have to say (out of experience now) is that
> > writing tests at the beginning does not always work,
> 
> I don't agree, I think it just indicates an incomplete understanding of the problem you're
> trying to solve...
> 
> > since it requires a
> > sound understanding of the problem domain, which I did not have at the time
> 
> ... :-)
> 
> I recommend getting a full understanding of the existing code _before_ you start changing
> it...
> 
> Seriously, keep up the good work, I'm really looking forward to using Formulator in Zope 3
> & the new ZMI, but bear in mind that we're all trying to create a graceful, tested,
> extendable, well documented and cruft free thing here. Lets not put in any "temporary
> hacks" 'cos experience should tell you by now that they'll still be around in 3 years time
> when we're all looking to write Zope 4 to eradicate the nasty crufty hacks in Zope 3 that
> no-one will quite own up to introducing...

-- 
Ideas don't stay in some minds very long because they don't like
solitary confinement.