Reference and Selective Reading

You do not need to read the source books front-to-back for this module. Use the concept pages and practice pages first. Open these local chunks only when you need alternate exposition, worked examples, or depth on a specific judgment call.

Source Roles

Source	Role	Why it is here
Clean Code (Martin)	Primary teaching source	Strongest for clarity, simple design, review vocabulary, stewardship
Good Code, Bad Code (Hansen)	Primary / judgment	Strongest for code-quality rubrics, testability, and dependency injection
Refactoring (Fowler)	Primary / tradeoffs	Strongest for when-to-refactor, YAGNI, two hats, and reversibility framing
Head First Design Patterns	Selective support	Pattern combinations and "pattern sense"
Design Patterns (GoF)	Reference only	Vocabulary and pattern-selection discussion; do not read cover to cover
OOAD	Selective support	When a diagram is warranted, which UML diagram to pick
Google eng-practices (external)	Primary external	Canonical code-review rubric and etiquette
joelparkerhenderson/architecture-decision-record (external)	Primary external	ADR templates and examples

Read Only If Stuck

Cluster 1: Integrating Patterns in Real Systems

• Head First Design Patterns: Intro to design patterns
• Head First Design Patterns: Designing the duck behaviors
• Head First Design Patterns: Decorator pattern
• Head First Design Patterns: Factory method defined
• Head First Design Patterns: Compound patterns
• Head First Design Patterns: King of compound patterns (MVC)
• Head First Design Patterns: May the force be with you (part 1)
• Head First Design Patterns: May the force be with you (part 2)
• Head First Design Patterns: Your mind on patterns
• GoF: How to select a design pattern
• GoF: Discussion of structural patterns
• Clean Code: Simple design rules
• Clean Code: Emergence, no duplication

Cluster 2: Code Review as a Design Conversation

• Clean Code: What is clean code (part 1)
• Clean Code: What is clean code (part 2) / schools
• Clean Code: Comments do not make up for bad code
• Clean Code: Clarification
• Clean Code: Redundant comments to scary noise
• Clean Code: We are authors
• Good Code Bad Code: Code Quality
• Good Code Bad Code: Code should work
• Good Code Bad Code: Summary
• Good Code Bad Code: Other engineers and code contracts
• Good Code Bad Code: Things obvious to you are not obvious to others
• Good Code Bad Code: Comments are a poor substitute for descriptive names
• Good Code Bad Code: Use comments appropriately

Cluster 3: Design Documents and Decision Records

• Clean Code: Attitude
• Clean Code: How would you build a city
• Clean Code: Scaling up, cross-cutting concerns
• Good Code Bad Code: How this book is organized
• Good Code Bad Code: How code becomes software
• Refactoring: Going further
• OOAD: Modeling OO systems -- choosing the diagrams
• OOAD: Building models to represent the system
• OOAD: Which UML diagrams should we choose
• OOAD: Sequence diagrams (MVC chapter)

Cluster 4: Pragmatic Tradeoffs

• Refactoring: Defining refactoring and two hats
• Refactoring: Why should we refactor
• Refactoring: When should we refactor (part 1)
• Refactoring: When should we refactor (part 2)
• Refactoring: Problems with refactoring (part 1)
• Refactoring: Problems with refactoring (part 2)
• Refactoring: YAGNI and the wider process
• Clean Code: Successive refinement
• Clean Code: Unit tests -- keeping tests clean
• Good Code Bad Code: Code Quality
• Good Code Bad Code: When layers get too thin
• Good Code Bad Code: Make code testable and test it properly
• Good Code Bad Code: Design with dependency injection in mind
• Good Code Bad Code: Don't make things visible just for testing
• Good Code Bad Code: Mocks and stubs can be problematic
• Good Code Bad Code: Reasons for using a test double

Cluster 5: Review Workflows and Craftsmanship

• Clean Code: Attitude
• Clean Code: We are authors
• Clean Code: Unit tests -- keeping tests clean
• Clean Code: Clean tests
• Clean Code: F.I.R.S.T.
• Clean Code: Classes should be small
• Clean Code: Maintaining cohesion
• Clean Code: Successive refinement
• Refactoring: Value of self-testing code
• Refactoring: When should we refactor (part 1)
• Refactoring: Why should we refactor

Optional Deep Dive

• GoF: Design problems (chapter 2) -- older but still-instructive problem statements across pattern categories
• GoF: Designing for change (part 1)
• Refactoring: Refactoring and performance -- tradeoff narrative between shape and speed
• Clean Code: Chapter 17 Smells and heuristics -- C1 inappropriate information -- useful catalogue for writing review comments
• Clean Code: G5 duplication to G11 inconsistency
• Clean Code: G12 clutter to G18 inappropriate static
• OOAD: Evaluating and improving the solution (part 1) -- book-length worked design-review example
• Head First Design Patterns: So you wanna be a design patterns writer

Concept-to-Source Map

Primary concept	Best source if stuck	Why this source
01 Choosing patterns as response to pressure	HFDP: May the force be with you (part 1)	Most explicit treatment of pressure-first thinking
02 Combining patterns	HFDP: Compound patterns	Walks through a multi-pattern feature with commentary
03 Simple design: the four rules	Clean Code: Simple design rules	Canonical, short statement
04 Code review rubrics	Good Code Bad Code: Code Quality	Cleanest short rubric; pairs with Google eng-practices externally
05 Writing review comments	Clean Code: Redundant comments to scary noise	Sharpens what "useful written English about code" looks like
07 Architecture Decision Records	Clean Code: How would you build a city	Motivates the why an ADR captures
08 Design documents	Good Code Bad Code: How this book is organized	Short example of shaping larger reasoning into a readable document
10 Over- vs under-engineering	Refactoring: YAGNI and the wider process	Canonical articulation of the tension
11 Designing for testability	Good Code Bad Code: Make code testable	Directly motivates seams without damaging the domain
13 Reviewable commits and PR shape	Clean Code: Successive refinement	Shows the value of incremental visible progress
15 Long-term stewardship	Clean Code: Attitude	Directly names the boy-scout-rule posture