Module 5: Applied Design & Code Review
This page aggregates the generated reference routes used by the learner-facing module.
- Semester:
semester-03-software-design - App:
foundations
Read only if stuck
- 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
- 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
- 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)
- 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: 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
- Clean Code: Clean tests
- Clean Code: F.I.R.S.T.
- Clean Code: Classes should be small
- Clean Code: Maintaining cohesion
- Refactoring: Value of self-testing code
- HFDP: May the force be with you (part 1)
- HFDP: Compound patterns
- Good Code Bad Code: Make code testable
Optional deep dive
- GoF: Design problems (chapter 2)
- GoF: Designing for change (part 1)
- Refactoring: Refactoring and performance
- Clean Code: Chapter 17 Smells and heuristics -- C1 inappropriate information
- Clean Code: G5 duplication to G11 inconsistency
- Clean Code: G12 clutter to G18 inappropriate static
- OOAD: Evaluating and improving the solution (part 1)
- Head First Design Patterns: So you wanna be a design patterns writer