A
program should never "just happen". It should be
designed. This means taking a step back from writing
code and
thinking about a number of things:
- What should this program do?
- What should this program not do?
- How can I make the program simple to understand in five years' time (of five weeks' time!)?
The first two points are generally addressed by system design methods.
The last point is, however, just as important in many commercial developments and - in general - gets left to the programmer. A program might be running for 30 years and, in that time, may need amending. The programmer who writes code that is easy to read is held in high esteem by the programmers who have to amend that code.
The "v model" for development shows that part of good design is the specification of both how the program should work and how it should be proven to work (i.e. tested). Good program design leads to straight-forward testing. If it seems difficult to write the test plan, perhaps the program design should be re-examined.
There is a very large number of methodologies on offer for program design. I am only acquainted with two: Jackson Structured Programming (JSP) and Object-Oriented Programming (OOP). As my knowledge of OO is limited, the following detailed comparision of OO methodologies may be of use: (http://www.ipipan.gda.pl/~marek/objects/TOA/OOMethod/mcr.html, A Comparison of Object-Oriented Development Methodologies - Copyright The Object Agency, Inc., 1995). (It's a very long textfile that aims to assist in evaluating different methods.)
JSP is based on the premise that a problem is solved by transforming input data into output data. JSP is a "strong" method - in that, for the restricted set of problems it can be usefully applied to, it is highly prescriptive on how to solve them. JSP programs should be simple, implementing a single transformation.
Traditional Structured Design (in fact, most "structured" methods) produces models that JSP can be used to implement. However, as noted below, it can also be used in an OO development.
OOP is based on the premise that a problem is solved by performing operations (methods) on objects. OOP is a "weak" method - in that it applies to a very wide range of problem sets but is not particularly detailed on how to solve them. It leaves you in the lurch when you want to know how to code the method! My usual option is to fall back on JSP - once the object and its methods are fully specified, the implementation of each method should be a simple transformation of input data (input request, event, initial object state) into output data (output response, trigger, updated object state).
This shortcoming with OO methods is discussed further in "Skill-Driven Design - An object-oriented software-design method" (http://www.vuniq.co.il/swtrain/new/avner/atskill.htm). A quick quote to supply the flavour of the article:
Functional-decomposition skills, on the contrary, are notoriously hard to acquire. To make things harder, for some obscure reasons of principle, the pioneers of object-oriented programming have removed the skill for functional decomposition from the object-oriented domain.
The article deals more with solving problems at the design level, rather than code level, but offers a much more apparent and appropriate means of performing funcional decomposition in an OO methodology. Another lovely quote:
What is our "greatness?" What is the feature that we intend to do better? This is the design focus.
What is it that we are trying to do, in the first place. What kind of information system is this? This is The Problem Space.
To apply OOP to a development requires OO methods from the outset.