Re: Detail first? Or Big Picture?
- From: "Twayne" <nobody@xxxxxxxxxxxxxxxxxxx>
- Date: Sun, 16 Mar 2008 17:24:23 GMT
What do YOU do when your classic VB project is nearing completion? Do
you spend a few days "tidying up"? Removing those redundant comments
that could be confusing rather than helpful if left in? What is your
development style? To address the details first and build your product
from them; or look at the big picture and decide how the application
is going to be used, knowing that the details will sort themselves out
later?
I am firmly in the latter camp. I always build some scaffolding, hang
some windows and doors off them (controls), stand back and contemplate
the overall look at feel. Maybe I'll remove a window and add a
chimney. Or change the angle of the roof pitch, or the colour of the
bricks. All these bricks and mortar are a metaphor for my "school" of
design - Rapid. Application. Development. Can't be rapid enough in my
book. I know of others who spend weeks designin' away, with ne'er a
sign of any application taking shape. But they are happy. They keep
their RAD picture in their heads. Fair enough.
Now I am approaching the end of my project, well, its initial
prototype at least, and I am in the process of removing those
redundant comments, removing obsoleted procedures or functions called
OldMakeLongInt or SearchString_2, which a sudden insight when I got
down to the details made me think of a better way to do something.
I am completely comfortable with my approach, though I know others
won't be. Finally, I'll probably add line numbers and error handlers
everywhere, though as I have long since had an add-in to automate this
task, it won't be the chore it once was.
MM
From a full fledged newbie:-- I gather as many "specs" as I can together & create an outline with
details a/r under each major heading.
-- Flow chart it to show navigation & dependencies
-- Proto the expected screens that might be expected & match to the
Flow chart.
-- Write skeleton menues
-- Assign module names & indicate all Publics
-- Decide reasonable order to write modules in.
-- Write & test modules as I go, marking same on flow chart if one
becomes done.
-- Write alpha test spec from the flow chart
-- Create Help from the program itself; haven't done F1 type help yet.
-- BETA with anyone who is willing (I'm not a pro).
And keep the written records updated all along, and a file of anything
new that I learned in the process.
Seems to work, for me at least, so far. A programmable keyboard and
'Remote Keys' a key/mouse macro generator helps tremendously, esp with
boilerplate.
I've also been known to let my personal-use programs write themselves
& not bother with any fore-design other than in my head. That works too
if it's something I want badly enough; the documentation is entirely in
the form of remarks/comments in the file. Requirements at the top of
the Main, nice to haves at the bottom.
--
Regards,
Twayne
Open Office isn't just for wimps anymore;
OOo is a GREAT MS Office replacement
www.openoffice.org
.
- References:
- Detail first? Or Big Picture?
- From: MM
- Detail first? Or Big Picture?
- Prev by Date: Re: How do i print the results from my SELECT Statement
- Next by Date: Re: VarPtr and passing variables by ref
- Previous by thread: Re: Detail first? Or Big Picture?
- Next by thread: Re: Detail first? Or Big Picture?
- Index(es):
Relevant Pages
|
