Re: How to learn software design
On Dec 19, 10:00 am, ta...@mongo.net (tanix) wrote:
In article <7p3lqhFfs...@mid.individual.net>,
e...@boese-wolf.eu (Eric =?utf-8?Q?B=C3=B6se-Wolf?=) wrote:
I know it is off topic, but maybe someone could give me a
hint for a good book or few tips on learning software design.
Ok, I am going to give you some tips.
You've raised an interesting point. And it is at least
partially true. However...
First of all, to learn software design, you'd better study
what is beauty. Yep, BEAUTY. Believe it or not.
Study beauty in what way? I'm not even sure you can study
beauty, per se, except from a philosophical point of view (what
is beauty?). Good software engineers do generally have a strong
sense of beauty, but it's not really something that you can
study, per se. Except maybe by reading beautiful code (and
there's not much of that published).
Then get into music. Believe it or not.
Music will teach you the structures unlike anything you are
likely to read in any so calles software book.
That's an interesting point. I once heard that you should never
employ a programmer who didn't play a musical instrument.
Something about the ability to be creative in a structured
environment.
I don't think that studying music is really the most rapid way
of learning software engineering, but I do think that if you
have a feel for music, it's a good sign that you'll probably be
able to become a good software engineer. There is some sort of
a relationship with regards to the most basic skills.
Then, try to understand programming as a system.
A program is a SYSTEM, a highly complex interactions,
a higly complex structure, and immensely complex logic.
Yes. That's why modern software design borrows heavily from
architecture (Design Patterns, for example, which were invented
by an architect).
Every proggram has millions of logical conditions,
every one of which must EXACTLY fit with all others.
Then you learn to state things clear and simple.
This is an essential point. According to Dijkstra, the two most
important skills necessary in order to be able to become
competent are mathematical reasoning and the ability to express
yourself well in your native language. People who can't write
clearly and concisely (in their native language---you can't
always judge by the quality of writing you see here, because
English might not be the author's native language) will never
become competent programmers.
[...]
Documentation of your source code and user documenation is one
of the MOST important things.
Good documentation. Written before you write a single line of
code. Totally aggreed.
Never EVER ignore errors. Handle ALL exception conditioins,
conceivable or not.
It's an error to ignore an error:-).
I'm not too sure what your point is. I would say that you must
define what the program should do for all possible input. (But
some of those definitions are more or less implicit. I've yet
to read a design specification which says that the program is
allowed to stop running if the machine is turned off. Although
at a higher level---I worked once on a system with a requirement
that the system continue to perform for up to 48 hours without
any external power. The system was for the electric company in
France, and I've always wondered if they didn't know something
they weren't telling the general public.)
If you make your algorithm BASICALLY work, but think that some
things may NEVER happen, think again. Becasue they WILL.
Yah. Someone will turn the machine off.:-) (Seriously, if you
mean what I think you mean, then I agree 100%. Consider all
possible inputs. In a multithreaded environment, consider all
possible thread switches.)
Document your source code in the most minute detail.
You'll never regret that one.
At the lowest level (and I'm not sure that's what you meant),
you can easily over-document. There's nothing worse that things
like:
++ i; // increment i
for ( int i = 0; i < 10; ++ i ) // loop 10 times...
and such. In practice, within the actual code (as opposed to
specifying exactly what the function guarantees), I've often
found the most useful documentation to be that which describes
what you didn't do: why you didn't use the obvious algorithm
(e.g. because it would fail in some exotic case).
But the level of documentation is more what I would consider
part of the process, and not how to design.
--
James Kanze