Dry Principle:
Every piece of knowledge must have a single, unambiguous, authoritative representation within a system.
Duplication can arise in one of the following categories:
- Imposed duplication developers feel they have no choice
- Inadvertent duplication developers don't realize that they are creating duplication
- Impatient duplication developers get lazy
- Interdeveloper duplication developers aren't aware of others on their team having already introduced the same knowledge to the system
One important but commonly ignored form of imposed duplication is in documentation. If documentation is overly specific, it must be changed as code is changed. So this is a form of duplication. Documentation written at a higher level perspective than the code avoids this. No documentation is better than incorrect or outdated documentation. There's always a risk in duplication that one instance of the knowledge will be updated while the other is left. With duplication in documentation it is assured that the documentation will be the piece that gets left behind.
Orthogonality signifies independence and decoupling of components in the system.
Two or more things are orthogonal if changes in one do not affect any of the others.
Orthogonality can help productivity, reduce risk, and make you more confident about changes to your code as your changes can be assured to only affect the component you're working on. Without orthogonality you'll see ripple effects in response to changes. It also makes unit testing easier to have very well defined isolated components.
No one knows what the future will hold
No one knows the future. So the architecture and integrations within a system should be thought about and coded defensively. Especially where change is likely, but really everywhere, reversability should be considered.
Important vendor integrations should happen in one place in the app, with an abstracted wrapper that be implemented for a different vendor if that's what the future holds.
Code should be "shy". A shy component:
- doesn't reveal itself to others
- doesn't interact with many others
Delegations should be explicit, and few as possible, as many as necessary.