Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Kent Beck came up with these four rules to help ensure simple (not simplistic) design. These rules are in priority order. I find them helpful to use when reviewing code either mine or other propels to validate against these rules.
Passes All Tests
First and foremost any system should be tested and all tests must pass – Simple as that. If a system is not or cannot be tested (in some form), then there is a good argument not to ship it
The primary aim of any software is that it works as intended. Tests are required to verify the system does what it should and acts as documentation to fellow programmers. This aids design and simplicity, as tight coupling makes it difficult to write good tests. More tests of high quality should automatically help to improve the code base and simplify the design.
The simpler a system is to test the more likely it is well designed.
Eliminate Duplication
Duplication is a hiding place for bugs and makes software more complex and harder to work on. It should be removed in all its forms.
Eliminating duplication is a very powerful way to simplify software. It makes code cleaner and easier to follow and maintain, reduces the likelihood of bugs and helps promote good design. Duplication takes many forms and can be hard to spot. Once code is done (i.e working) then is the time to revisit the code to refactor to remove duplication and tidy up class/variable names.
The security blanket of the tests make this step painless.
Express Intent
The developer should write code that makes it obvious what he or she was intending to do.
Code should be easy to read and understand. Well named and defined classes, methods and variable names. It all too easy to write code you understand at the time, but how easy will it be for others to maintain in the future? As systems grow and become more complex there is greater chance of misunderstanding.
The clearer the code, the less time others will take to pick it up and ultimately reduces the cost of bug fixing and new features.
Fewest Elements
A system should be no bigger than it needs to be.
Keep class and method counts as low as possible, but without sacrificing the other rules (this is the least priority). A system should only be as big as it needs to be, so don’t clutter it with unnecessary code/classes/interfaces etc that add no value. This increases complexity and ultimately slows down future development.