is*********@gmail.com said:
Particularly for medium-sized (10,000 ~ 20,000 lines) programs,
Er, those are iddy-biddy little programs.
LOC Range Category
0 Vapourware
1-9 IOCCC
10-99 Exercise/Example
100-999 Library update
1000-9999 Utility
10000-99999 Small program
100000-999999 Medium-sized program
1000000-9999999 Large program
10000000+ Very large program
(Source: BSI, 2008 [1])
what
are useful strategies to design them before coding?
Identify the requirements. If you know how to implement these requirements,
write down how to do that. Otherwise, break the requirements down into
simpler sub-problems, and recurse. Look for commonalities between various
parts of the problem, and use those to factor out functionality. Look for
aspects of the problem that are general computer problems rather than
aspects of this particular problem, and see whether you have existing
library solutions for those parts. If not, consider creating them this
time round, to make life easier next time round.
My strategies are:
1. Imagine what the final program would look like. Write down
options.
2. Write down many structures, [...] many function prototypes, [...]
many macro definitions [...]
I hope I'm wrong, but this almost sounds like you're inventing these things
at random! I would suggest that you think in terms of modules. "I will
need a module for dealing with customers, a module for dealing with
suppliers, a module for managing transactions..." and so on.
But having to change the original design during coding really troubles
me. Do you have any suggestions to avoid doing this?
Even if you get the design right (which you probably won't because hardly
anyone does, and this is normally *not* their fault because normally they
haven't been told correctly which problem they're supposed to be solving),
by the time it's finished the requirements will have changed, which
necessarily means a change in design. Welcome to the ever-changing world.
That's why the "Cathedral" design process doesn't work very well - it can't
respond quickly to changing requirements. Write well-modularised code,
usefully solve *one* problem, and release the code, asking for review
comments and telling your users when, roughly, to expect the next release
(tomorrow? day after? next week?) and what problem it intends to solve,
and so on round all the problems. That way, your users become involved
iteratively in your design process, and you can satisfy their needs much
more quickly, effectively, and flexibly.
[1] Those who are wondering whether I mean the British Standards Institute
need wonder no longer. I don't.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999