This post is a part of a series on the classic book: The Pragmatic Programmer. This post is a summary of chapter 2. If you haven't read the summary of chapter 1, you can find it here, The Pragmatic Programmer: Book Summary (Part 1)
The topics covered in this chapter are
- Topic 8: The Essence of Good Design
- Topic 9: DRY - The Evils of Duplication
- Topic 10: Orthogonality
- Topic 11: Reversibility
- Topic 12: Tracer Bullets
- Topic 13: Prototypes and Post-it Notes
- Topic 14: Domain Languages
- Topic 15: Estimating
If you would like to start from the begining, the summary of Topics 1 - 8 was covered in the previous post here.
The Essence of Good Design
What makes a design good? The authors state that an important characterstic of a good design is that,
Good design is easier to change than bad desgin
Given that software (as opposed to hardware) is supposed to change over the course of it's life this is quite important. A good design should be ETC - easier to change.
ETC is one of many popular acronyms that the authors of this book have created. Another one is DRY. But even though many of us know about these acronyms, not many are aware of their origin.
Most of the principles in design and architecture are to make a software ETC.
Decoupling, Single resposibility principle, Proper naming all help us in creating desgins that are easier to change.
Now, how do we make something ETC?
The book says that ETC is not a rule, it is a value. And it should work the way other values like honesty and kindness work. It should be "subtly nudging you in the right direction". Whenever you write some code, you can ask yourself if what you wrote makes the system ETC. You can ask the same question when you read code written by someone else or even by you.
There are times when don't even know what kind of changes to expect. In such cases it is better to make the entire subsystem replacable (decoupled)
A suggestion in the book (which I haven't tried yet) for developing this instinct is to keep a journal to record the cases where the decision seems difficult and add a tag in the source code to that journal entry. Then when the time comes where you to change that code refer back to the journal and see how of your thought process still makes sense.
DRY: The Evils of Duplication
DRY Don’t Repeat Yourself
Make It Easy To Reuse
Two things are Orthogonal if a change in one does not affect the other. If the UI can be changed without any impact on the database, then these components can be said to be orthogonal. Non orthogonal things are inherently more complex to operate and fix.
- Gain Productivity
- Reduce Risks
Eliminate Effects Between Unrelated Things
How to apply orthogonality?
If I dramatically change the requirements behind a particular function, how manymodules are affected?
- Decoupled code (Shy modules)
- Minimal global data
- Avoid similar functions
Constant critism of your own code is a good to improve it's quality.