Patterns that pay off
summary
Clear claims and concrete practices: treat design patterns as preventative vs reactive (use a solution only when a problem appears), prefer monolith first until microservices’ costs justify splitting, stop using production dumps — seeds not dumps with randomized seed data and factory states, enforce four eyes code review + self-review, typehint custom Request classes, use presenters/view‑models/responsibles for view data, prioritize tests that would save your job, and favor small, easy‑to‑delete code to lower cost of change.
AI-written summary · about
chapters (15)
- 0:00Start
- 6:27Cost of Change Time it takes to adapt the existing application logic to new business realities.
- 8:11Write code that is easy to delete.
- 9:48PART 11 Matt's Patterns
- 10:23Three types of pattern 1. Process 2. Architecture 3. (Re)factoring
- 11:20No precogs
- 13:07Codebase Consistency
- 15:31Four Eyes
- 18:32Monolith first
- 20:28Seeds, not Dumps
- 23:04Test to save your job
- 27:30Seed each test
- 29:52Custom Requests
- 32:54View Data Composition
- 39:51Not everyone needs a root canal.
related talks
40mRAMP up your testing solution: test automation patterns
47mHow To Build Future Proofed Applications
32mDemystifying Design Patterns: A Practical Guide for Developers
48mAnti-Patterns in the Wild
54mBreaking Down Your Build: Architectural Patterns For A More Efficient Pipeline
45m'Writing code that lasts'...or writing code you won't hate tomorrow
58mTechnical Practices that Take Time but Save Time
32mN design patterns you might actually use