Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder3.hal-mli.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!news.glorb.com!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail From: Lew Newsgroups: comp.lang.java.programmer Subject: Re: Standard Design and Development Methodologies Date: Sat, 19 Nov 2011 20:13:11 -0800 (PST) Organization: http://groups.google.com Lines: 89 Message-ID: <4908121.2133.1321762391730.JavaMail.geo-discussion-forums@prou19> References: Reply-To: comp.lang.java.programmer@googlegroups.com NNTP-Posting-Host: 216.239.45.130 Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-Trace: posting.google.com 1321762397 1948 127.0.0.1 (20 Nov 2011 04:13:17 GMT) X-Complaints-To: groups-abuse@google.com NNTP-Posting-Date: Sun, 20 Nov 2011 04:13:17 +0000 (UTC) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=216.239.45.130; posting-account=CP-lKQoAAAAGtB5diOuGlDQk0jIwmH0T User-Agent: G2/1.0 X-Google-Web-Client: true Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:10084 Arved Sandstrom wrote: > Novice wrote: >> What are the standard design and development methodologies being used in= =20 >> systems departments these days and, ideally, where can I find tutorials = for=20 >> them, preferably free and online?=20 >>=20 > 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. >=20 > Ultimately _every_ software development methodology (SDM) boils down to: >=20 > 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. >=20 > 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.=20 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. =20 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. =20 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. --=20 Lew