Principles of Good Design

It seems that we are on a never ending quest for seeking an ultimate answer to an immortal question: "What is a good program?". In a previous post I discussed the difficulties inherent in this question.

People are constantly trying to make progress with respect to this question. Here are several (very well put) suggestions for producing high-quality code.

Excerpt #1, “Continuous Design” / Jim Shore:

Continuous design makes change easy by focusing on these design goals:

• DRY (Don't Repeat Yourself): There's little duplication.
• Explicit: Code clearly states its purpose, usually without needing comments.
• Simple: Specific approaches are preferred over generic ones. Design patterns support features, not extensibility.
• Cohesive: Related code and concepts are grouped together.
• Decoupled: Unrelated code and concepts can be changed independently.
• Isolated: Third-party code is isolated behind a single interface.
• Present-day: The design doesn't try to predict future features.
• No hooks: Interfaces, factory methods, events, and other extensibility "hooks" are left out unless they meet a current need.
  
  

Excerpt #2, “Orthogonality and the DRY Principle” / Andy Hunt and Dave Thomas:

All programming is maintenance programming, because you are rarely writing original code. If you look at the actual time you spend programming, you write a bit here and then you go back and make a change. Or you go back and fix a bug. Or you rip it out altogether and replace it with something else. But you are very quickly maintaining code even if it's a brand new project with a fresh source file. You spend most of your time in maintenance mode.

So you may as well just bite the bullet and say, "I'm maintaining from day one." The disciplines that apply to maintenance should apply globally.

...

Most people take DRY (Don't Repeat Yourself) to mean you shouldn't duplicate code. That's not its intention. The idea behind DRY is far grander than that.

DRY says that every piece of system knowledge should have one authoritative, unambiguous representation. Every piece of knowledge in the development of something should have a single representation. A system's knowledge is far broader than just its code. It refers to database schemas, test plans, the build system, even documentation.