Re: Urgent!!! UPGRADE METHODOLOGY
On Sep 26, 3:07 pm, "Phlip" <phlip...@yahoo.com> wrote:
dondora wrote:
While I was making the program,
I comformed to the design procedure which is widely used in practice.
I drew up requirement specifications and drew actor-class diagram, use
case and related diagrams.
And then I extracted candidate classes and drew up data dictionary and
blah blah sequence, class diagrams also.
I don't know what the professors have told you, but that's not
a primary development "methodology". Modeling is just a way to
visual a proposed or existing design; it's not a complete
system to verify that design.
Obviously, design is a creative activity, which takes place
first in the designer's head. However, in a very real sense,
there is no design until it's on paper (or "electronic" paper,
written down in the computer somewhere). UML is probably the
most widespread way of doing this, at least for larger projects.
(And just as obviously, until the design has been written down
somehow, it's impossible to verify it.)
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. There's no
silver bullet. Testing doesn't drive design; in some cases, you
can't even know what to test until part of the design has been
specified. (Don't get me wrong: testing is important, to catch
out the cases where you've done something else wrong. But
anytime a test fails, the first thing you do is revisit your
process, to see what you did wrong upstream.)
Don't put the cart before the horse.
That means, for each line of code you intend to write, you
first write a simple test case that fails because the line is
not there yet.
The order is irrelevant. The important thing is that before you
write any line of code (test or not), you have some sort of
design.
This is not a "unit test" or a "QA test" - it's just a test
that can fail for the correct reason - the line is not there
yet. You run the test and successfully predict it will fail,
before you upgrade the tested code.
Running a test that you know will fail, because you've not
written the code yet, is just a waste of time.
When you pass the test, you write whatever sloppy bad design
you need. It will only be a few edits-worth of sloppy code, so
it's safe. When all the tests pass, only then do you upgrade
the design. You try to see how many lines of code you can
delete, and how you can simplify the design. You should only
make small edits and pass all the tests after each one.
If at any time the tests fail unexpectedly, you should revert
and try again. People using that system always report these
benefits:
- almost no debugging
- simple clear designs
- no bugs released to production
- your project velocity does not decay over time
- you can deploy to production daily
People who use that system don't produce high quality code,
which can be used reliably in large systems.
"Project velocity" is the average time required to implement one feature.
An application is more than just a collection of features.
This system has a lot of mindshare among our industry's leading
consultants
You mean you and a couple of other amateurs who aren't involved
in serious software? I don't know of any serious specialist in
software engineering who recommends anything so silly.
- the people whose job is rescuing huge projects from years of
junior programmers attempting to over-design everything the way their
professors told them to.
Does it occur to you that in well run companies, the design
isn't done by junior programmers, but by professionals, applying
professional methodology (which includes modeling, and a lot of
other things). You might want to take a look at
http://www.sei.cmu.edu/, for example (which is the ultimate
reference for software engineering issues);
http://www.idinews.com also has some good articles about
software development.
--
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