- A Mantra for Development
- The Pathologies of Code Qualities
- Avoid Over- and Under-Design
- Minimize Complexity and Rework
- Never Make Your Code Worse/Only Degrade Your Code Intentionally
- Keep Your Code Easy to Change, Robust, and Safe to Change
- A Strategy for Writing Modifiable Code in a Non-Object-Oriented or Legacy System
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
Avoid Over- and Under-Design
This essentially means you should put in the correct amount of design. Overdesign is putting in things that add complexity to the code that may or may not be needed. Note that the key word here is "complexity." We're not as worried about the time you take as much as we are about how you leave the state of the code. If the work you've done does not raise the complexity of the code you have, then no worries. In other words, putting in an interface where one may or may not be needed is not necessarily a bad thing if everyone understands interfaces. Interfaces aren't really complexity-adders in our mind. They are a holder for an idea. However, putting in a complex parameter list (or using a value object to hold a parameter, say, when one isn't needed) would be raising complexity.
Under-design is actually a euphemism for "poor code quality." We view under-design as having taken place when high coupling or weak cohesion is present. Typically, proper encapsulation is also not present. So, avoiding overdesign means make your code changeable, but don't add things you don't need now. If you need them later, the changeability of the code will enable you to do that with less, if any, extra cost. Avoiding under-design mostly means making sure your code is changeable.