Design Principles Roadmap¶
"Principles are the distilled experience of the people who got burned before you. You can relearn them the hard way, or you can read the list."
This roadmap catalogs the code-level design principles that good engineers reach for instinctively — KISS, YAGNI, DRY, low coupling, high cohesion, and the rest. Each is a small, sharp rule of thumb. None is absolute; they sometimes conflict, and part of the skill is knowing which one wins in a given trade-off.
Looking for architecture-scale principles (component cohesion/coupling, the dependency rule)? See Clean Architecture.
Looking for named, reusable structures (Factory, Observer, Strategy)? Those are patterns, not principles — see Design Patterns.
Principle vs Pattern vs Practice¶
These three words get used interchangeably and shouldn't be:
| What it is | Example | Lives in | |
|---|---|---|---|
| Principle | A rule of thumb that guides decisions | "Keep coupling low" | this roadmap |
| Pattern | A named, reusable solution structure | Factory Method | Design Patterns |
| Practice | A repeated activity that builds quality | TDD, refactoring | Craftsmanship Disciplines |
A principle tells you what to aim for; a pattern is one concrete way to get there; a practice is the habit that keeps you there.
Sections¶
Principles are grouped by the scope of the decision they govern — from a single line of code outward to the relationships between whole modules.
01 — Generic¶
Broad rules that apply to almost any line of code.
| # | Principle | One-liner |
|---|---|---|
| 01 | KISS | The simplest thing that works is usually the right thing. |
| 02 | YAGNI | Don't build it until you actually need it. |
| 03 | Separation of Concerns | Each section should address one concern, independently. |
| 04 | Code For The Maintainer | Write for the person who debugs this at 3 a.m. |
| 05 | Avoid Premature Optimization | Make it work, make it right, then — only if measured — make it fast. |
| 06 | Optimize for Deletion | Code that's easy to delete is easy to change. |
| 07 | DRY | Every piece of knowledge has one authoritative representation. |
02 — Coupling & Cohesion¶
How parts of a system should — and shouldn't — depend on each other.
| # | Principle | One-liner |
|---|---|---|
| 01 | Minimise Coupling | Reduce how much a change in A forces a change in B. |
| 02 | Maximise Cohesion | Group things that change together; separate things that don't. |
| 03 | Connascence | A precise vocabulary for kinds and strengths of coupling. |
| 04 | Law of Demeter | Don't talk to strangers — only your immediate collaborators. |
| 05 | Composition Over Inheritance | Prefer "has-a" over "is-a" for flexibility. |
| 06 | Orthogonality | Unrelated things should stay unrelated in the system. |
| 07 | Robustness Principle | Be strict in what you send, liberal in what you accept. |
| 08 | Inversion of Control | "Don't call us, we'll call you" — let the framework drive. |
03 — Module & Class¶
Principles that shape the boundary of a single module or class.
| # | Principle | One-liner |
|---|---|---|
| 01 | Encapsulate What Changes | Find the hotspot of change and hide it behind an interface. |
| 02 | Command Query Separation | A method either does something or answers something — never both. |
04 — SOLID¶
The five object-oriented design principles that travel together.
| # | Principle | One-liner |
|---|---|---|
| 01 | Single Responsibility | A class should have one, and only one, reason to change. |
| 02 | Open/Closed | Open for extension, closed for modification. |
| 03 | Liskov Substitution | Subtypes must be substitutable for their base types. |
| 04 | Interface Segregation | Many small client-specific interfaces beat one fat one. |
| 05 | Dependency Inversion | Depend on abstractions, not concretions. |
| 06 | SOLID as a Whole | How the five interlock, and the smells that signal a violation. |
Already covered elsewhere (cross-linked, not duplicated): Boy Scout Rule → Clean Code → 21; Hide Implementation Details → Clean Code → 22; FIRST & Arrange-Act-Assert → Craftsmanship Disciplines → Test Design.
How to Use Principles¶
- They are heuristics, not laws. "Higher-ranked principles usually beat lower-ranked ones" — but usually, not always.
- They conflict. DRY pushes you to consolidate; Separation of Concerns and "Optimize for Deletion" sometimes push you to keep things apart. Naming the conflict is half the design conversation.
- The Rule of Three. Don't abstract on the first duplication, or even the second. Wait until the pattern is real before paying the cost of DRY.
Status¶
Content-complete. All 23 topics across the four sections are written following the Code Craft file convention — five levels each (junior · middle · senior · professional · interview). All content in English.