Re: Books for learning how to write "big" programs
On May 24, 12:33 am, Ian Collins <ian-n...@hotmail.com> wrote:
James Kanze wrote:
On 23 mai, 10:36, Matthias Buelow <m...@incubus.de> wrote:
James Kanze wrote:
And you're really wasting your time if you write a single
line of code without knowing why, or what it should do---and
what isn't written down, isn't known.
This might be true for some projects but certainly not in the
general case -- sometimes, the goals to achieve are somewhat
blurred or might not yet be known in entirety and have yet to
be discovered. In such situations, explorative programming is
(imho) more effective than trying to pen it down on paper
beforehand.
Yes, but you still have to decide what you're exploring. You
don't just write random code; you write code to fulfill some
specific specification.
As specified by your unit tests.
And how do you specify your unit tests?
The requirements from the customer are often very vague,
especially in the web application world. In some domains, the
best way to get detailed requirements from a customer is to
start building the application. Once they see something, they
then realise exactly what they want it to do.
Certainly. But you do have to specify what you're going to
code. That doesn't mean that the specification is cast in
stone, but that you have a trace of what you've done, and that
you know what you've done. (For certain things, it's probably
acceptable to specify "whatever"---but you should at least know,
and have written down, that it doesn't matter, and that whatever
happens to come up as a result of the implementation is fine.
And if the customer later declares that it is important, then
you put it in writing, and do code review and add tests to
ensure that it behaves like that in all situations, and after
all further modifications.)
The quality of requirements varies from the exact (say a
safety critical device driver) to the virtually nonexistent (I
started what turned out to be a one year web project with a
single page sketch). We have to be able to adapt our
development process to match.
I'm not sure that we agree on what is meant by "specifications".
In a very real sense, all projects start out as a vague idea,
which is fleshed in little by little. And all successful
projects end up with a working system, with code. The only
issue is how much of this is done exclusively by the client, how
much exclusively by the development team, and how much in
collaboration.
It's true that in many of my applications, an important part of
the specification has been an RFC (or several); if you're
writing a RADIUS server (for dynamic allocation of IP
addresses), you don't "experiment" to find out what the RADIUS
protocol should be.
Whether you're sure that it's the right specification or not
is separate issue---in practice, I'd say that it's even more
important to document what the code is doing if you're not
sure about the specification.
Indeed, half the battle is getting the customer to agree (or
if they are game, write) acceptance tests. In the vague and
woolly world of web based applications, tools like FitNesse
have evolved to help users write tests.
In a visual application, I can imagine that having the customer
"sign off" screen shots could be an important part of the
specification process; if you have a tool which allows the
customer to actually generate the screen shots himself, so much
the better. That still leaves a number of questions open: in a
web application, for example, different levels of logging are
doubtlessly required. You can't really expect the customer to
write, or even understand, test programs which verify that the
logs are correct.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34