I am certainly no expert on this, but for myself I try to do both.
I write my Fusedocs and then my code. After my code is all written, I go
back and clean up my Fusedocs to make sure that they match how my code was
actually written. Admittedly, I have neglected this last step a few times.
When I remember to go back and do it, however, I certainly think it helps
me learn how to plan and Fusedoc future applications better.
When I come back later to makes changes to a fuse, I change the
Fusedocs to match my changes. This adds a little time to every effort, but
I have already found that it greatly reduces stress headaches when trying
to figure out what a fuse does.
As a side note, I remember going back to make changes to one of my
first applications, which was not done in Fusebox. I had around 400 lines
of code in one file. It had lots of comments throughout, but it still took
forever to find the section I wanted to modify. Talk about a stress
headache! That had to be one of the primary motivations to look into
Fusebox in the first place! I think Fusedocs really enhance that very benefit.
Steve
At 08:53 AM 5/24/2002 -0400, you wrote:
>Steve,
>
>I will confess to not using Fusedocs the way they are meant, but I have
>always wondered, do you find you have to go modify the fusedocs you
>pre-wrote for an application very often?
>
>For example, the application I am working on right now, I started with one
>method of passing variables around from page to page. Then proceeded to a
>second method, and finally a third (which I now believe is the best way
>for the complexity of the forms I am using). If I pre-wrote the fusedocs
>I would at best have to modify it once to match my final method of
>handling, and in a worst case I would modify it every time thinking that
>"this time" I am doing it the best way.
>
>Perhaps my perspective is merely one of not having years of dynamic web
>development behind me? That as time goes on I would find the need to go
>back and redo whole sections/pages of code to be better would lessen, and
>therefore I could approach the "write the doc, code the doc" (once),
>levels of achievement?
>
>I have stayed away from fusedocing because I know that I will go back
>through my code several times and it will end up potentially different, or
>I may have completely overlooked a component I needed and have to add it
>in later.
>
>I'm not sure what the answer to my ponderings above should be... I *know*
>I would like to "code the doc", but I am not sure if it of large benefit
>when I go back and rewrite code alot to be better...
>
>Cheers,
>Keith.
>
>
>
> >>> [EMAIL PROTECTED] 05/23/02 09:43pm >>>
>Rey Muradaz wrote:
> >
> > Yes, but that info would be pretty helpful if you're trying to add on
> another floor, don't you think? (BTW, I hope you're not saying that all
> of your development projects end up in a heap of wreckage . . . :).
> >
>
>Maybe, maybe not. I've tried this two ways and they both seem to work
>about the
>same, but for different reasons. I've tried one way where I make changes
>to the
>prototype, then use the existing fusedoc to modify the new one. I've also
>tried,
>making changes to the prototype, scraping the old fusedoc and refusedocing the
>changed pages in the new prototype. I guess it has to do with how much you're
>changing in each fuse. If you're changing a lot, that old blueprint will just
>slow you down.
>
>Here's an analogy. My mother has been a home renovation architect for 30
>years.
>If the house she's working on will be ripping off the roof to put on another
>floor, having the blueprints for that roof won't do her any good. She just
>needs
>measurements to create the new blueprints. The NEW blueprints get
>submitted to
>the engieers for structural review and the builders to build the new
>floor, not
>the old ones.
>
> > Documenting up front is the best, but documentation at *any* point in
> the process is still useful when you have to pick up someone else's work
> weeks, months or (yikes!) years later.
>
>I'd say it fully depends on the type of documentation you get. Stupid
>documentation does you nothing regardless of when it's written, like this:
>
><!--- loop over query --->
><cfloop query="somequery">
>
>or
>
><!--- setting first_name variable --->
><cfset first_name="Steve">
>
>That just won't do you any good. Now Fusedocs documentation at any point
>in the
>process... it might help it might not. I'd still start with the wireframe,
>go to
>the prototype, fusedoc, fusecode and unit test, regardless of how much was
>already built and working. If *some* of the fusedocs were already written,
>then
>great, it helped. If you added new stuff, new fusedocs would need to be
>written.
>
>btw, as far as wreckages go. Sure, i've had my share of wreckages, and my
>share
>of successes. My biggest flop crashed 2 weeks before we were going to sign a
>contract for $26,000,000 (that's a lot of zeros!!). That was the day I
>began to
>really take Fusebox seriously.
>
>Steve Nelson
>
> >
> > REM O-
> >
> > >>> [EMAIL PROTECTED] 05/23/02 12:36PM >>>
> > Is it? Knowing how much weight a steel beam can hold seems pretty
> pointless to
> > me.... if the building has already collapsed.
> >
> > Steve Nelson
> >
> > "Benjamin S. Rogers" wrote:
> > >
> > > > Steve is right; documenting post-development is pointless;
> > > > Fusedocing up front is powerful.
> > >
> > > Pointless? That's a bit extreme, isn't it?
> > >
> > > Benjamin S. Rogers
> > > http://www.c4.net/
> > > v.508.240.0051
> > > f.508.240.0057
==^================================================================
This email was sent to: [email protected]
EASY UNSUBSCRIBE click here: http://topica.com/u/?bUrFMa.bV0Kx9
Or send an email to: [EMAIL PROTECTED]
T O P I C A -- Register now to manage your mail!
http://www.topica.com/partner/tag02/register
==^================================================================
