Re: Standard Design and Development Methodologies
Arved Sandstrom wrote:
Novice wrote:
What are the standard design and development methodologies being used in=
systems departments these days and, ideally, where can I find tutorials =
for
them, preferably free and online?
You could probably do worse than to read
http://en.wikipedia.org/wiki/Software_development_methodology. This is
of value primarily because it introduces a lot of common terminology.
Ultimately _every_ software development methodology (SDM) boils down to:
1. requirements analysis - understanding what the client needs you to do;
2. analysis & design - how you intend to meet those needs. See
http://en.wikipedia.org/wiki/Object-oriented_analysis_and_design, since
we are talking Java, for general concepts;
3. implementation - actually write code;
4. testing - ensuring that your code, as written, satisfies the
requirements;
5. maintenance - nurturing the application over its lifespan.
How all the various approaches differ is how they break up and sequence
these activities. What really matters is that all these activities are
important.
There's a comprehensive little pamphlet reviewing various software developm=
ent methodologies called /Wicked Problems, Righteous Solutions/ by DeGrace =
and Stahl, 1990, that is as relevant today as when first published.
Its main conclusion, after a very neutral overview of the extant pet theori=
es, is that successful methodologies rest on two key features: an individua=
l who maintains the project architecture and structures in his/her own mind=
, and iteration.
As such an individual (as you should be, too), I have a toolbox of ways to =
look at a programming assignment - a kit of ontologies.
First and most fundamental skill - to look it up. Whatever the unfamiliar =
concept or skill, there is never an expert enough who's patient enough with=
time enough and communication talent enough to explain it for you. You ha=
ve to be able to do with fragments of advice (at best) and what you discove=
r for yourself - through hard, hard study and very pragmatic experimentatio=
n. A former mentor of mine trained me that any IT person spending less tha=
n 20% over and above their normal work time to study and practice was doome=
d to fall behind.
'Struth.
As for ontologies, the most useful ones I know are event-driven programming=
, object-oriented programming, MVC (model-view-controller), layers (Law of =
Demeter), and "noun-and-verb" modeling. That last is my own term for using=
the language of the problem domain (its nouns and verbs) to define your pr=
ogram structures.
There's one style trick that induces better code: Keep it short. After ab=
out 500 lines of code and comment (yes, and comment) your class should feel=
too large, and after about 700-800 lines you should be castigating yoursel=
f.
The pressure to keep it short helps you think more clearly about structure.
And there's one mandatory, cross-methodology practice: Javadoc the shit ou=
t of your code. Document private and package-private methods and all stati=
c variables down to private. The extra asterisk at the start of the commen=
t block hurts nothing.
Don't use specious comments, the kind that repeat what the code already say=
s:
for (Foo foo : bunchOfFoos) // operate on each of the Foos
Pfeh! If a person doesn't know what a for-each loop is, such a comment wil=
l not rescue them.
Do liberally comment anything that makes a maintainer go, "Hmm."
// volatile: thread calling close() might not be same as called perform()
private volatile boolean isStopping;
This advice might not fit your idea of what constitutes a "methodology", bu=
t for Pete's sake, think. What does that "ology" suffix buy you but buzzwo=
rd compliance? The real need is for a _method_, a process by which you can=
produce effective, reliable, correct software on time to spec. In the end=
it's all about your personal commitment and skill.
--
Lew