Book Exercise Lanes
This module's exercise system is book-driven plus repo-driven. Use these local chunks and your own codebase for targeted volume after you have already learned the concept from the guide.
How To Use This Page
- Finish the relevant concept page first.
- Solve at least one exercise from memory on a codebase of your own.
- Only then open the matching book chunk.
- Keep a mistake log with tags such as
private-is-not-encapsulated,SRP labelled but not split,OCP without 2nd variant,Feature Envy missed,comment that lies, orspeculative abstraction.
Lane 1: SOLID identification exercises
Use this lane when the vocabulary is present but the labeling is unreliable.
Book chunks:
- Clean Code: Single Responsibility Principle
- Head First Design Patterns: The Open-Closed Principle
- OOAD: Why Pixel is not SolidRectangle (LSP)
- OOAD: The Interface Segregation Principle
- Good Code, Bad Code: Design with Dependency Injection in mind
- Clean Code: Systems and Dependency Injection
Target outcomes:
- 5 class-level SRP labels on real code with named stakeholders
- 3 OCP-violation labels where a switch/if-chain repeats and a new variant is on the roadmap
- 2 LSP analyses: parent contract written out, subtype checked against it
- 2 ISP analyses: client × method matrix drawn
- 3 DIP direction sketches: arrow pointing from policy to detail, with the fix proposed
Lane 2: Naming and function exercises
Use this lane when your functions and names are "fine" to you but opaque to a reviewer.
Book chunks:
- Clean Code: Meaningful Names -- introduction
- Clean Code: Meaningful Names -- pronounceable names
- Clean Code: Meaningful Names -- meaningful context
- Clean Code: Functions -- Small, blocks and indenting
- Clean Code: Functions -- Do one thing
- Refactoring: Extract Function (Part 1)
- Refactoring: Extract Function (Part 2)
- Good Code, Bad Code: Use comments appropriately
- Good Code, Bad Code: Comments are a poor substitute for descriptive names
- Refactoring: Mysterious Name smell
Target outcomes:
- 10 renames with before/after and a sentence of justification each
- 3 stepdown rewrites where a 40+ line function becomes a top-level plan + named sub-functions
- 1 comment audit on a real file: classified, deleted, or rewritten as appropriate
- 2 Extract Function drills on code where the extracted function gets a name you are happy to read out loud
Lane 3: Smell-spotting exercises
Use this lane when your smell vocabulary needs volume.
Book chunks:
- Refactoring: Mysterious Name to Duplicated Code
- Refactoring: Long Function to Long Parameter List
- Refactoring: Global Data to Mutable Data
- Refactoring: Divergent Change to Feature Envy
- Refactoring: Data Clumps to Repeated Switches
- Refactoring: Loops to Message Chains
- Refactoring: Middle Man to Alternative Classes with Different Interfaces
- Refactoring: Data Class and Comments
- Clean Code: Smells -- G5 Duplication to G11 Inconsistency
- Clean Code: Smells -- G12 Clutter to G18 Inappropriate
Target outcomes:
- a smell-card deck with at least 15 smells, each with a one-line definition and one paired move
- 8 smell-labels on a real file with direct code quotes as evidence
- 2 change-pattern analyses (is the recent change concentrated, scattered, or mirrored?)
- 1 parallel-hierarchy diagnosis with a composition-based fix sketched
Lane 4: Mini-refactor exercises
Use this lane when you can name smells but hesitate to act.
Book chunks:
- Refactoring: Extract Function (Part 1)
- Refactoring: Move Function (Part 1)
- Refactoring: Encapsulate Variable
- Refactoring: Encapsulate Collection
- Refactoring: Replace Primitive with Object
- Refactoring: Extract Class
- Refactoring: Introduce Parameter Object
- Refactoring: Replace Conditional with Polymorphism (Part 1)
- Refactoring: Replace Conditional with Polymorphism (Part 2)
Target outcomes:
- 2 Extract Function refactors on real code, fully typed and still passing tests
- 1 Extract Class refactor where a Data Clump becomes a domain type with behavior
- 1 Move Function refactor that fixes a named Feature Envy
- 1 Replace Conditional with Polymorphism where the switch is repeated in at least three places
- 1 Introduce Parameter Object refactor shrinking a signature with four-plus parameters
- 1 "didn't refactor" case where you documented why YAGNI applied and you chose not to move
Self-Curated Problem Set
Build a custom set with these minimums:
- 5 cohesion/coupling labels on real classes
- 5 SOLID-letter violations with stakeholder or mechanism evidence
- 5 renames with pre/post comparison
- 5 smells with refactoring moves paired
- 3 system-level (Divergent Change / Shotgun Surgery / Parallel Hierarchy) change-pattern analyses
- 2 written "when not to" memos
Completion Checklist
- Completed at least one lane in full
- Logged at least 12 mistakes with tags and corrections
- Wrote at least 8 full sentence-form design critiques on real code
- Executed at least 4 real refactors on a codebase you maintain
- Wrote at least 2 "did not refactor" justifications based on YAGNI