Re: Urgent!!! UPGRADE METHODOLOGY
On Sep 28, 4:39 am, "Phlip" <phlip...@yahoo.com> wrote:
dondora wrote:
Well, my question causes a dispute.
Sorry it looks like that. In many circles the matter is quite
settled.
Quite. Take a look at the SEI site, for example. Software
engineering is actual a fairly mature discipline, even if a lot
of developers (including some who are experts in other things,
such as software design) choose to ignore it.
And you could also try "Design by Contract", to much the same
effect.
The best way to do something is often the simplest, but there
are always newbies who need to be brought up to speed. The
only "debate" here has been whether we should write test cases
just before or just after writing the tested code.
I'm not even sure that that's being debated; I certainly don't
think it matters (and have expressed that opinion). My
impression was that the debate was over whether there were
phases that should precede writing tests or code: a separate
design phase.
Nobody here has advocated you _not_ write automated tests.
Very true. NO development methodology would ever allow that.
In industry, typically, the check-in procedures for the software
will run the unit tests, and won't accept the check-in if they
fail.
I've determined to conform to the design methodology I
talked(requirement specifications, use casees, etc).
Again: Those are not a methodology. And if you describing
doing all of them first, before any coding, then that is
"Waterfall", which is among the worst known methodologies.
There, you're being intellectually dishonest. There is no such
thing as a "waterfall" methodology, and never has been; it's a
strawman that was invented for the sole purpose of criticising
it, and justifying some new approach. If you don't know what
the code you want to write is supposed to do, then you can't
write either the tests or the code. And if you haven't put it
down in writing, then you don't know it. It's that simple. The
"requirements specification" must be complete for the code you
write. (That doesn't mean, and has never meant, that it is
complete for every aspect of the final system. The requirements
specification may evolve, just like everything else in the
system.)
You might want to read http://www.idinews.com/waterfall.html for
more details.
There's no problem with things I've done in my project as
you ask me. I just wanted to know there's systematic
methodology as I did. Anyway, TDD looks bad.
What have you read about it? Try Steve McConnell's /Code
Complete, 2nd Ed/. And nobody has said that people using TDD
never document what they are doing. Read more.
When it comes to time to handing over your own
program in industry, you just give code?
And tests.
What you hand over depends on the contract:-). Code, tests,
documentation... Whatever the customer wants (and is willing to
pay for). I'm sure, for example, that you provide user manuals,
if that's part of your responsibility in the project---you don't
really expect users to figure it out from the tests.
Typically, of course, you will provide a requirements
specification (at least partial) much, much earlier. When you
specify the price. Because most customers don't particularly
like writing blank checks: they want to know what they will get,
for what price.
I want you to imagine picking one of two new jobs. This
example is contrived - the real life example is always
somewhere in between - but it illustrates the situation. At
either job, your first task will be adding a feature to 1
million lines of well-written C++ code.
At Job A, the code comes with lots of nice, accurate,
reliable, indexed requirements documents, design model
diagrams, and use cases.
At Job B, the code comes with almost no documents, 1.5 million
lines of clearly written and simple test cases, and a Wiki
documenting and running test cases covering all the inputs and
outputs the users expect.
Again: intellectual dishonesty. Have you ever heard of a
company that had a good enough process to produce the
documentation of job A, which didn't have automated tests as
part of the process.
Now lets see what you do at your first day at Job A. You make
a change. Then, for hours, you slowly read all that
documentation, and you manually operate the program, making
sure your change did not break any of the existing features.
When you make that change, you have the odious choice to add
new code, or to change existing code. If you get this choice
wrong (likely), the design quality will go down. Further, if
you make any mistake, you will probably spend a long time
debugging to figure out what went wrong.
At Job B, during and after your first change, you quickly run
all the tests. They work like little elves reading all that
documentation, and applying all those checks for you. If you
break something - or even if the elves _suspect_ you might
break something - you have the option to revert your change
and try again.
You forget the essential: if the role and the responsibilities
of the class in the project are well defined and documented (job
A), you understand what you are doing, and your code will be
correct first time. If they're not (job B), you guess, run the
tests, they fail, guess something else, run the tests, that
fails as well, etc., until you guess right.
You have the option to _not_ debug.
Understand the elves are not omniscient - they only know what
they are told. So did the documentation at Job A. But the
elves prefer to err on the side of caution. Many of your edits
that should have worked, the test cases will reject them!
You will work faster and safer at Job B.
Have you any real measured studies to support such a ridiculous
claim.
If a test case fails, its assertion diagnostic should describe
what went wrong. These test cases form a living documentation,
showing you what systems, structures, and behaviors the code
should reveal.
Next, each "use case" was expressed as a high-level test in
that Wiki. This forced the code to be testable, which
overwhelmingly improved its design, and decoupled its objects.
This improves communication with your users' representatives.
No more hand-waving or white-boarding when discussing
features. You can see them in action.
Real life, of course, is not so distinct. Many projects have
no tests whatsoever (and many also have no documentation!).
In practice, such companies went out of business a long time
ago. At least in the fields I work (where software usually has
to run 24 hours a day, 7 days a week, with contractual penalties
for down time).
Well-managed projects usually find some balance between
automated tests and of _reliable_ documentation. (Tests can't
lie like some documentation can!) So the question resolves to
one point: At crunch time, when the programmers are doing
something important, would you rather they devote their energy
to documentation? or to automated tests? Which one is more
important for your project's success?
Unless you have both, you've failed.
--
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