MbUnit : Design Standards

This page last changed on Jul 18, 2005 by jflowers.

Good Design

Practices

Test First
This is the practice of writing unit tests before writing production code.
Write More Here!

What is a unit test?
Where can I find how to do this?
Payback on Code Debt
As a project progresses life happens and shortcuts must be taken. The shortcuts or debts accumulate. At some point they need to be paid off. This can happen by refactoring during the project or on a great walup at the end of the project.

This is from that paperback in the Martin Fowler signature series.

Coding by Intention
Coding by intention is the practice of pretending a piece of function you need already exists and is
in the form you want it to be in. In other words, if you find that you have to write some function,
instead of coding it in the place you need it run, put in a call to method you pretend exists. In our
example in the "Write Tests First" section, this would mean writing the method we described as:
```
s= getStatus();
s= formatStatus(s);
s= encryptString(s);
transmit(s);
```
This is much better than writing one long method that is all implementation. This gives us an easy
to read method that describes what is happening. Note that each of these methods has strong
cohesion and should be correctly coupled because no knowledge of how it is being implemented is
being taken advantage. Since each method has a well-defined interface with a clear contract, each
of these should also be relatively easy to test.
Coding by intention assists:
Testability: because a well-defined intention is easier to test.
Cohesion: because the intention should be about one thing, resulting in method cohesion
Encapsulation: because it encapsulates the implementation of the method being defined
Correct coupling: because the calling routine is written only to the interface
Readability: because functions are contained in well-named methods.
It may not be quite as clear that it also helps eliminate redundancy, but in practice it does. This is
because coding by intention results in stronger cohesion which makes it easier to identify when a
redundancy has been introduced.

Code Qualities and Practices

Refactoring
Up Front Design
Don't do more than you need
Don't do more than you need is our version of XP's "Doing the simplest thing possible". We
prefer to state it this way because it isn't always clear what simple is. Don't do more than you need
springs from too many projects doing much more than needed. Common examples include:

features that are implemented that are never used
bells and whistles that are added because developers were "sure" they were useful
frameworks that handle more than is ever required of them
We're not suggesting architecture isn't important or that you shouldn't think ahead. The difficulty
is that developers often think much too far ahead (or not ahead at all). Doing something you need
now is a good idea. Doing something you may need in the future is often a waste of time. What's
worse, is that it often causes the design problem to greatly increase in magnitude. Over- designed
software can be just as problematic as under- designed software.
The bottom line is, if you follow this mandate, you may improve the quality of your code because:
1. You might not actually need it (YAGNI), thereby saving time to work on things you do
need.
2. If you do need it in the future, you may be smarter at that point when you have to
implement it.
3. Not doing things you don't need to do now allows you to focus on those things you do need
to do now
4. If you do need it later, more of the system will be built that should make writing the
function easier.

Code Qualities and Practices

There is an old saying: "Fool me once, shame on you. Fool me twice, shame on me." This is a powerful attitude in software design. To keep from loading our software with Needless Complexity, we may permit ourselves to be fooled once. This means we initially write our code expecting it not to change. When a change occurs, we implement the abstractions that protect us from future changes of that kind. In short, we take the first bullet, and then we make sure we are protected from any more bullets coming from that gun.
From Robert Martin's "Agile Software Development"

Continuous Integration