There are the four simple rules for software design that you always should follow. They are, in order of importance:
- Tests passes
- Reveal intent
- No duplication
- 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
- Inspiration to this blog post came from Corey Haines and Alexandru Bolboaca at the Code Retreat Krakow 2011
- Thomas Sundberg – The author
[...] los entwickeln. Doch die ersten Aufgaben folgten schon bald: in der nächsten Runde sollten die 4 Regeln des einfachen Designs beachtet werden. Adrian machte aber auch nochmal klar, das ein Code Retreat nicht zwangsläufig [...]
Pingback by blaulabs » Blog Archive » Get your hands dirty – ein Code Retreat! — October 25, 2011 @ 17:17
s/Also, no method should not have more then one level of abstraction./Also, no method should have more than one level of abstraction./
Comment by David — October 29, 2011 @ 12:47
I think the level of abstraction is covered within the second rule, reveal intent. If you have different levels of abstractions within the same method, you are not clear and are therefore not revealing intent properly.
But I totally agree that having the same level of abstraction is crucial. But that is not limited to methods, classes should also have the same level of abstraction.
Comment by Thomas Sundberg — October 30, 2011 @ 10:42
I also agree but “no method should not have more th*a*n one level of abstraction” says the opposite thing. That’s why I thought theres a “not” too much.
Comment by David — October 30, 2011 @ 11:35
Now I saw what you meant. And yes, there were a double negation I had missed.
Thanks for pointing it out.
Comment by Thomas Sundberg — October 30, 2011 @ 16:31