You may know Kent Beck’s four rules of simple design. According these, simply designed code:
— passes the tests,
— reveals intentions,
— shows no duplications,
— have fewest elements.
I guess you can find lots of comments about it on the Internet. Now here’s mine.
Passes the tests
Is that really a rule of good design? Isn’t it a rule for overall good piece of software? Beck focuses on testing as he coined the term and wrote a lot about TDD. Why not ‟design should be driven by test” then? Your whole design is not required to be driven by test, you can plan a minimal design as you start writing a feature. This statement is not directly linked with TDD. Yet, whatever your strategy is, parts of your design should be covered by automated tests and your test should keep passing. If you do not test your units decoupled from each other and, more important, decoupled from the infrastructure, you cannot run them as often as you should. Thus you're not sure your design keeps passing the tests.
Reveals intentions
Good design is not simply an assembly of generic patterns. You should not structure your code with packages named controllers or strategies. Your structure should reveals programmer’s intentions and business’s intentions. The code should tell what t is designed to do, using shared business metaphors, AKA ubiquitous language.
No duplication
A client once demanded me ti voluntarily introduce duplication in code. His argument was: ‟if I need to change code used by part A, I don’t want the changes to affect part B.” He had his own experience and practices like hot fixing shell scripts in production. In the general case this is a fallacy. If two parts use the same code, it should be in one place. If it occurs in the application lifetime for part B to need a similar yet distinct code than part A, you can then decline used code in strategies. Do not do that when it’s not needed. It’s premature optimization (bad thing).
Fewest elements
You should be able to justify the existence of every piece of your design and code. This justification should not start with ‟maybe in the future we’ll need to…” since this future might never come. A great justification for a piece of design is tests. ‟I needed this interface so I could unit test this part of the code”. I get mad when I navigate in the code and keep arriving on silly unjustified interfaces.
