Four rules of simple design

Filed under: Software craftsmanship, — Tags: Automated test, DRY, Don't repeat yourself, Kent Beck, SRP, Simple, Single responsible principle — Thomas Sundberg — 2011-04-06

There are the four simple rules for software design that you always should follow. They are, in order of importance:

  1. Tests passes
  2. Reveal intent
  3. No duplication
  4. Small

These rules are always followed by all responsible developers. If you don't follow them, you are not a responsible developer. Let's go through the rules in more details.

Rule 1: Test passes

All test should always pass when you change any software. This means that there must exist tests. The test must be possible to execute easily and they always has to pass. If they don't pass, work on the code until they do. If you for some reason allow them to fail and don't work on the code to fix them, you are on the path towards disaster. Small problems usually grow up and become large problems.

What is meant by tests? Test can be anything from unit tests, integration tests to acceptance test. They must automated so they can be executed frequently without the risk of manual errors. Manual testing is not included in the definition of tests.

Rule 2: Reveal intent

Always reveal your intent when you write software. This means that all names, variables, methods, classes, modules and so on always have to be obvious and easy to understand. When these properties are fulfilled, and when another developer with no knowledge of the current system easily can find his way around, you have revealed the intent in a good way. So in short, naming and structure.

Rule 3: No duplication

No duplication seems easy to state. But what should not be duplicated? Obviously code should not be duplicated. Harder to spot, but even more important, is to avoid duplication of structures. This boils down to the DRY (Don't Repeat Yourself) principles.

Rule 4: Small

The final rule is that all you create should be small. This means small methods, small parameter lists, small classes and small modules. This boils down to the SRP (Single Responsibility Principle). Everything should have one and only one responsibility and one and only one reason to change. Any method, class, or module that solves more than one problem should be divided into two or more. A method should not have more then one level of abstraction. Any methods that mixes abstraction levels must be divided into two or more.

Conclusion

A lot more could be said about simple design, but then the definition might become complicated and that is not simple.

So always remember KISS, Keep It Simple Stupid.

Resources



(less...)

Pages

About
Events
Why

Categories

Agile
Automation
BDD
Clean code
Continuous delivery
Continuous deployment
Continuous integration
Cucumber
Culture
Design
Executable specification
Gradle
Guice
J2EE
JUnit
Java
Linux
Load testing
Maven
Mockito
Pair programming
PicoContainer
Programming
Public speaking
Quality
Recruiting
Requirements
Scala
Selenium
Software craftsmanship
Software development
Spring
TDD
Teaching
Technical debt
Test automation
Tools
Web
Windows
eXtreme Programming

Authors

Thomas Sundberg
Adrian Bolboaca

Archives

Meta

rss RSS