>From some private discussions (edited a bit):
> > Ok. So, I'll double check the code, get some samples together,
> > check it in, and send in a summary email to the list covering
> > everything you mentioned above. Sounds like a good plan. Thanks a
> > lot for your advice.
>
> pretty much sums it up yes. So your basic process:
>
> 1) analysis of use case
> 2) figure out problem domain
> 3) figure out where to satisfy use case
> 4) code solution
> 5) test
> 6) post solution for peer discussion and review
> 7) refactor
> 8) test
> 9) post revised solution
> 10) summarize
> 11) satisfactory solution? If not, back to 6. If yes:
> 12) document
>
> did I get that right? Probably.
Yes. The process is right on. Perhaps there's a 13) Fix any bugs :)
It all reads like common-sense. I guess somtimes, people need it
to be pointed out to them :) but it's great to have a guide of
what to do, especially how to handle the chicken & egg issues like
'commit, then post', or 'post, then commit', etc.
> > Absolutely. I'll be saving this email away in my
> > 'worth-its-weight-in-gold' folder for I'm sure, many future
> > references. :)
>
> cool! If this is indeed such a valuable insight, perhaps it should be
> somewhere for the world to read....hmm.
Yes, I was going to say it would be great as part of a
newbie-committer-kit or the like ? or available somewhere else
easily accessible.
If y'all could comment and perhaps expand a bit, I'll put a webpage somewhere.
Or, if I missed the mark completely, I'll do nothing =)
regards,
- Leo Simons
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
