Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > Java > Standard Design and Development Methodologies

Reply
Thread Tools

Standard Design and Development Methodologies

 
 
Novice
Guest
Posts: n/a
 
      11-19-2011

I have a very general question that isn't really even specific to Java but
I'd appreciate your thoughts on this.

I'm a Java hobbyist. I've been writing code in Java for a while because I
like the language but haven't really used current standard design and
programming methodologies in a formal way to develop my code, sticking to
older methodologies that I learned long ago, like structured programming
and structured design. I'm thinking of trying to get paying work as a full-
time employee in a company using Java but I think I'm going to have to
acquire some new skills to be a credible candidate for a junior position in
systems development.

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?

I expect that I will have to get at least a working knowledge of a bunch of
things, including OO Design, Patterns, and a dozen other things to have any
chance but, as a Chinese philosopher once said "a journey of a thousand
miles begins with a single step". I'd appreciate your help in building a
list of the things that someone like your employer would want met to have
before considering me for a junior position writing Java.

--
Novice
 
Reply With Quote
 
 
 
 
Arne Vajh°j
Guest
Posts: n/a
 
      11-20-2011
On 11/19/2011 2:42 PM, Novice wrote:
> I have a very general question that isn't really even specific to Java but
> I'd appreciate your thoughts on this.
>
> I'm a Java hobbyist. I've been writing code in Java for a while because I
> like the language but haven't really used current standard design and
> programming methodologies in a formal way to develop my code, sticking to
> older methodologies that I learned long ago, like structured programming
> and structured design. I'm thinking of trying to get paying work as a full-
> time employee in a company using Java but I think I'm going to have to
> acquire some new skills to be a credible candidate for a junior position in
> systems development.
>
> 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?
>
> I expect that I will have to get at least a working knowledge of a bunch of
> things, including OO Design, Patterns, and a dozen other things to have any
> chance but, as a Chinese philosopher once said "a journey of a thousand
> miles begins with a single step". I'd appreciate your help in building a
> list of the things that someone like your employer would want met to have
> before considering me for a junior position writing Java.


OOA/OOD/OOP + design patters seems to be what to focus on.

GoF book
Code Complete
Applying UML and Patterns/Larman
Effective Java/Bloch

could be useful books to study.

Arne

 
Reply With Quote
 
 
 
 
Arved Sandstrom
Guest
Posts: n/a
 
      11-20-2011
On 11-11-19 03:42 PM, Novice wrote:
> I have a very general question that isn't really even specific to Java but
> I'd appreciate your thoughts on this.
>
> I'm a Java hobbyist. I've been writing code in Java for a while because I
> like the language but haven't really used current standard design and
> programming methodologies in a formal way to develop my code, sticking to
> older methodologies that I learned long ago, like structured programming
> and structured design. I'm thinking of trying to get paying work as a full-
> time employee in a company using Java but I think I'm going to have to
> acquire some new skills to be a credible candidate for a junior position in
> systems development.
>
> 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?
>
> I expect that I will have to get at least a working knowledge of a bunch of
> things, including OO Design, Patterns, and a dozen other things to have any
> chance but, as a Chinese philosopher once said "a journey of a thousand
> miles begins with a single step". I'd appreciate your help in building a
> list of the things that someone like your employer would want met to have
> before considering me for a junior position writing Java.
>

You could probably do worse than to read
http://en.wikipedia.org/wiki/Softwar...nt_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-...sis_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.

It's probably best not to fixate on any given methodology. Just learn up
on the highlights of each, and keep in mind that all of them ultimately
boil down to requiring competence in the same skills. You'd be
interested initially in object-oriented analysis (OOA), object-oriented
design (OOD), and how to test your code (starting with unit testing and
perhaps functional testing).

Like Arne suggested, "Effective Java" by Bloch is a great book. So is
"Code Complete". IMO I wouldn't bother buying a copy of the GOF design
patterns book; borrow from a university library or locate a decent
website instead. Read some Martin Fowler
(http://martinfowler.com/intro.html). Don't get hung up on specific
methodologies (did I say that already?) - no project ever succeeded or
failed just because of what methodology a team used. Get some
familiarity with UML but don't go overboard with it.

My own specific suggestion - read
http://www.agilemodeling.com/artifacts/crcModel.htm (Scott Ambler is
also a good author). CRC is not just useful in agile.

If your understanding of persistence (databases) is not solid - in your
estimation, bone up on that.

If you don't have one already, select another OO programming language to
learn. You can make a lot more headway in learning all of the above if
you're not tied to one specific language. Just my opinion.

AHS
--
You should know the problem before you try to solve it.
Example: When my son was three he cried about a problem with his hand. I
kissed it several times and asked him about the problem. He peed on his
hand.
-- Radia Perlman, inventor of spanning tree protocol
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      11-20-2011
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/Softwar...nt_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-...sis_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 development 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 theories, is that successful methodologies rest on two key features: an individual 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 withtime enough and communication talent enough to explain it for you. You have to be able to do with fragments of advice (at best) and what you discover for yourself - through hard, hard study and very pragmatic experimentation. A former mentor of mine trained me that any IT person spending less than 20% over and above their normal work time to study and practice was doomed 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 usingthe language of the problem domain (its nouns and verbs) to define your program structures.

There's one style trick that induces better code: Keep it short. After about 500 lines of code and comment (yes, and comment) your class should feeltoo large, and after about 700-800 lines you should be castigating yourself.

The pressure to keep it short helps you think more clearly about structure.

And there's one mandatory, cross-methodology practice: Javadoc the **** out of your code. Document private and package-private methods and all static variables down to private. The extra asterisk at the start of the comment block hurts nothing.

Don't use specious comments, the kind that repeat what the code already says:

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 will 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", but for Pete's sake, think. What does that "ology" suffix buy you but buzzword compliance? The real need is for a _method_, a process by which you canproduce effective, reliable, correct software on time to spec. In the endit's all about your personal commitment and skill.

--
Lew
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      11-20-2011
Lew wrote:
> There's a comprehensive little pamphlet reviewing various software development methodologies called /Wicked Problems, Righteous Solutions/ by DeGrace and Stahl, 1990, that is as relevant today as when first published.


http://www.google.com/search?q=ISBN%20013590126X

--
Lew
 
Reply With Quote
 
Derek K. Wodenhouse
Guest
Posts: n/a
 
      11-20-2011
On 19/11/2011 11:13 PM, Lew wrote:

> 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 program structures.


That last is also known as "programming in Lisp".
 
Reply With Quote
 
Lew
Guest
Posts: n/a
 
      11-20-2011
Derek K. Wodenhouse wrote:
> Lew wrote:
>> 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 program structures.

>
> That last is also known as "programming in Lisp".


Trivially, since the technique applies irrespective of platform.

It's also known as "programming in /X/", where /X/ is any programming language.

Thank you for your useful observation.

--
Lew
 
Reply With Quote
 
Derek K. Wodenhouse
Guest
Posts: n/a
 
      11-20-2011
On 20/11/2011 2:45 AM, Lew wrote:
> Derek K. Wodenhouse wrote:
>> Lew wrote:
>>> 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 program structures.

>>
>> That last is also known as "programming in Lisp".

>
> Trivially, since the technique applies irrespective of platform.
>
> It's also known as "programming in /X/", where /X/ is any programming language.


Not nearly as strongly. Lisps let you reify nearly any program
abstraction, and build a bridge from the solution domain to the problem
domain, expressing most of the business logic in problem domain terms. A
common program design in another language consists of a problem domain
focused library, plus an application layer atop that that contains the
business logic but is still largely written in solution domain terms,
with a sprinkling of problem domain nouns and verbs. A common program
design in Lisp consists of a domain-specific language for the problem
domain, in Lisp, and an application in that language with a sprinkling
of generic-Lisp nouns and verbs (mostly lists and data structure
traversals, and/or numbers and arithmetic -- much of which might be
regarded as present also in the problem domain).
 
Reply With Quote
 
Robert Klemme
Guest
Posts: n/a
 
      11-20-2011
On 11/20/2011 09:49 AM, Derek K. Wodenhouse wrote:
> On 20/11/2011 2:45 AM, Lew wrote:
>> Derek K. Wodenhouse wrote:
>>> Lew wrote:
>>>> 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 program structures.
>>>
>>> That last is also known as "programming in Lisp".

>>
>> Trivially, since the technique applies irrespective of platform.
>>
>> It's also known as "programming in /X/", where /X/ is any programming
>> language.

>
> Not nearly as strongly. Lisps let you reify nearly any program
> abstraction, and build a bridge from the solution domain to the problem
> domain, expressing most of the business logic in problem domain terms. A
> common program design in another language consists of a problem domain
> focused library, plus an application layer atop that that contains the
> business logic but is still largely written in solution domain terms,
> with a sprinkling of problem domain nouns and verbs. A common program
> design in Lisp consists of a domain-specific language for the problem
> domain, in Lisp, and an application in that language with a sprinkling
> of generic-Lisp nouns and verbs (mostly lists and data structure
> traversals, and/or numbers and arithmetic -- much of which might be
> regarded as present also in the problem domain).


It's also pretty easy to create DSL's in - say Ruby - so Lisp is not
unique with respect to that. One can go even further and call any Java
library (in fact, _any_ library) a domain specific language. The
difference with Lisp is that it's basic syntax is trivial (sexpr) and it
has Macros which can make special forms look like regular function calls
by which means you can do things in this language which you cannot (or
not as easily) in others.

Kind regards

robert
 
Reply With Quote
 
Arved Sandstrom
Guest
Posts: n/a
 
      11-20-2011
On 11-11-20 12:13 AM, Lew wrote:
> 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/Softwar...nt_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-...sis_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 development 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 theories, is that successful methodologies rest on two key features: an individual who maintains the project architecture and structures in his/her own mind, and iteration.
>

[ SNIP good stuff ]

I hesitated to start talking about methods/"methodologies" in my first
post, since it was getting lengthy. Or as you've phrased it, key
features of successful methodologies. However I would agree that an
iterative approach is most suitable for most projects.

In that regard I'd caution the OP that waterfall is still popular and
common, and that a lot of shops advertise that they are iterative+agile
when in fact they are doing more, and smaller, waterfall projects. It's
not quite the same thing.

On the subject of "an individual who maintains the project architecture
and structures in his/her own mind", this often won't correspond to
titles or labels (like "architect"). Another way of looking at it is
that you should have an individual who is the "coordinator", who can
guide and plan the work of the individual domain experts - the developers.

AHS
--
You should know the problem before you try to solve it.
Example: When my son was three he cried about a problem with his hand. I
kissed it several times and asked him about the problem. He peed on his
hand.
-- Radia Perlman, inventor of spanning tree protocol
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: DBMS versus XML APIs (was "any (preferably open source) staticanalysis tool or methodologies/studies to translate ANSI [C|C++] or javacode to XML?") Joe Kesselman XML 0 09-27-2011 12:52 PM
Which Verification Methodologies Are You Using? harrytheasicguy@gmail.com VHDL 1 02-05-2009 08:54 PM
java testing methodologies, choosing the appropriate one! hvt Java 0 02-20-2007 07:24 AM
Have you adapted any software methodologies into your hardware work? Vinh Pham VHDL 5 12-08-2003 05:41 AM
C++: OO methodologies A C++ 3 11-26-2003 04:56 PM



Advertisments