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:
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.
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.
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.
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.
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.
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.
RSS