Re: C++ fluency
On May 7, 5:41 pm, Noah Roberts <n...@nowhere.com> wrote:
James Kanze wrote:
One very important point: you talk here about "changing" an
existing program. If you don't have an existing
architecture to interact with, then you have to develop that
first. And that's largely where I see problems with TDD
(supposing that is the only design tool you're using).
Of course it's not the only design tool I'm using.
In order to understand the use of *Test Driven Development* in
the terms of the only area of research I've seen it used, you
need to learn about Agile development. Of course, many things
are meant by Agile development but there's plenty out there to
read about it and there's certainly many general themes that
are shared by most Agile methods.
Yes. There is, in fact, too much "agile" out there. If it's
not "agile" and doesn't use OO, it won't sell.
Regretfully, unlike the case of OO, I didn't learn agile before
it got to that state, so it's hard for me to talk about it.
What I actually know about it is all marketing blather, which
doesn't mean much. (I don't like the fact that it uses a
loaded, but meaningless word, to describe itself. Good
programmers were "agile" long before it became an in
methodology.) And there's really too much "agile" now to learn
it---how do you separate the wheat from the chaff?
My impression of TDD started out much like that, and my
impression is that some of the other posters are still
presenting it like that. But you have been clear that you are
talking about a specific tool, to solve a specific problem, so
we can speak rationally about it. And maybe I'll learn
something.
Architecture is, of course, one of those areas where people
are still trying to figure out what to do. I know a web
search for Agile and Architecture turns up a video, because I
watched it.
What I do is write prototypes. Prototypes are not tested and
aren't expected to fully function. I still write unit tests
though and still generally use TDD but in the prototyping
stage I'm prepared to throw much out and sometimes break out
of better habits. It's a tool for thinking about the problem
(remember, I am NOT the person that said unit tests help you
stop thinking).
Yes. In a way, a prototype is a test of the architecture.
(I've also seen prototypes used as tests of the specifications.
This is particularly useful for graphic applications, where the
user often really doesn't know what he wants until he sees it.)
Another type of test. And we agree that tests are a good thing.
And in a real way, I guess, using a prototype to fix the
specifications could be called test driven design, or at least
test first design. You don't commit to the final specifications
until you've "tested" them with the user. Of course, I first
learned about this technique for developing user interfaces back
in the '70s, when it was called simply "prototyping".
To describe the process lets say I'm writing a simple drawing
program. It's a GUI so I already know certain things:
Document/View or MVC or something generally like one of those;
Command; I probably have a few state machines, especially for
the canvas controlling aspect; etc... It's not like I enter
each problem entirely blind, I have past experience helping me
solve similar problems.
Yes. The "in" word for that is "design patterns". In this
case, IMHO, the word is associated with something new (or at
least it was for me): the patterns have a name, and are more or
less formallized, where as before I had heard of design
patterns, it was all very ad hoc (but I did draw on my
experience).
I scratch out a UML diagram that I think will generally work.
Now I have a few class names so I create a project solution
(VS), a unit test project within it, and files with those
names. I have a general idea how many of the above mentioned
patterns look in the generic sense so I start there. When
specifics come up I address them by writing a unit test for
whatever feature I need from that unit. I test the view by
making sure "View" is an abstraction that doesn't require GUI
and mocking it with some sort of streamer.
At any rate, we don't just take a blank slate and instantly
start writing production code based on nothing. The company I
am working for just started a new product in fact and it's
taken us more than a month to come up with an architecture
we're confident will adapt well. Believe it or not, it's
simpler than any of the various others we tried and leaves
much to decide later. Trying to answer too much too early can
lead to monsters. As they say in the video I mentioned,
"Answer only what makes the rest of the answers easy."
To conclude, I don't know where people got the idea that unit
tests are the *only* design tool that people using TDD use.
If I said I use UML to create my designs would you come to the
same assumption??
Without more information, perhaps. UML is also an acronym (and
while a very useful tool, oversold in some milieux---and overly
condemned in others).
I have a stack of books 5 feet high on design, patterns,
etc... I have UML, prototyping, unit tests, and my
experience. I have MANY tools. Unit tests are a single tool
in my arsenal, but a very important one. Designs are
emergent, they come from the problem you're trying to solve,
and unit tests help explore and expose that design.
It sounds like our basic strategies aren't all that different.
--
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