Re: Urgent!!! UPGRADE METHODOLOGY
On Sep 27, 10:32 am, Ian Collins <ian-n...@hotmail.com> wrote:
James Kanze wrote:
On Sep 26, 3:07 pm, "Phlip" <phlip...@yahoo.com> wrote:
One primary development methodology that is deceptively simple
but extremely effective is Test Driven Development, with
Refactoring.
No professional would make such a silly statement.
I would, and so would any member of my team.
There's no silver bullet.
No one disputes that.
That's apparently what Philip was claiming. Use TDD, and you
don't need anything else. Testing is an essential part of
software development, but it isn't everything.
Testing doesn't drive design; in some cases, you
can't even know what to test until part of the design has been
specified.
We probably work in different worlds, my clients often either
don't really know what they want or they are chasing a rapidly
evolving market, so at the beginning of a project, there is
little, if anything to design.
If you don't know what the project is supposed to do, you can't
very well design it. Of course, you can't code it either, and
above all, you can't write tests to verify that it does it.
Requirements do evolve. The user's idea of his requirements
also may become more precise as time goes on. But that doesn't
mean you don't design---just the opposite: you intentionally
design in flexibility where you know things are going to change.
And you rework the design each time his requirements evolve.
(One frequent problem, of course, is that the user wants
flexible requirements, but a fixed price. But that just doesn't
work; you can't fix a price without knowing the actual
requirements. And of course, if the user then changes them, you
re-estimate, and fix a new price. After which, he either
forgoes the changes, or accepts the new price.)
I'm sure there are domains where the requirements are an
invariant and a well though out design is a good approach.
One of these days I might get to work on one!
I don't think it's that black and white. Every project I've
ever seen or heard of has some fixed requirements (it shouldn't
crash, regardless of the input), and some that evolve. A well
thought out design isn't cast in stone; it will evolve, just as
anything else will. (A well thought out design may help in
estimating the cost of a given evolution, of course.)
Don't put the cart before the horse.
Writing tests before the code is both more enjoyable and leads
to better, more thorough tests.
If you find that to be true, do so. I prefer the inverse, but
with regards to implemention code and tests (which are, of
course, also code), the order is really irrelevant, and each
developer can do whatever he feels like. The question is rather
one of design vs. code/tests: without the design, how do you
know what classes will even be needed.
Developers hate going back to write tests for exiting code and
tend to do a piss poor job when they do.
And then their code doesn't pass review (which, of course,
includes the unit tests, and validates their completeness).
In this regard, you might care to read
http://www.idinews.com/agileDoc.html. It doesn't cover the
question of TDD so much as basic professionalism; a professional
doesn't "do a piss poor job" just because he doesn't consider
something very interesting. And if he does, then that's a
problem, regardless of the methodology being used.
Having said that, of course, I would repeat what I said before.
Both the code and the tests must be written, regardless. And
the order isn't really that important; the code isn't finished
until it passes the tests. If you find it more agreeable to
write the tests first, and then the code, I don't see where that
would cause any problem. I generally do the reverse, but that's
just because that's the way I feel most comfortable. And in
practice, it's probably mixed for both of us: I'll write the
constructors, and the accessor functions used in the tests, and
test them, then generally add one or two functions at a time,
with their tests, until the class is complete. But whichever
way you do it, you have to know what to write, which means that
you have to know what the class is supposed to do, which means
that you must know the requirements. (In just about every place
I've worked, too, you have to make an estimation of cost and
time before you begin writing the code. On the basis of the
stated requirements, of course.)
--
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