99 Bottles of OOP A Practical Guide to Object-Oriented Design (JavaScript Edition) (Sandi Metz, Katrina Owen, TJ Stankus)（Z-Library）

【One-Line Pitch】 A hands-on, example-driven guide that teaches object-oriented design (OOD) principles through the deceptively simple "99 Bottles of Beer" song, showing you how to write code that is both understandable today and changeable tomorrow. Ideal for JavaScript developers (with Ruby/PHP variants available) who want to move beyond syntax and master the art of refactoring, testing, and finding the right abstraction. 【Book Arc】 - **Opening (~0%–9%)**: Introduces the core tension in OOD—code must be concrete enough to understand yet abstract enough to change—and presents four different solutions to the 99 Bottles problem, ranging from "Incomprehensibly Concise" to "Speculatively General," to illustrate the continuum of design choices. - **Early (~9%–25%)**: Deep-dives into evaluating code quality using facts and metrics (like Cyclomatic Complexity and ABC size) rather than opinion, and argues for "Shameless Green"—the simplest, most intention-revealing solution—as the starting point for good design. - **Early (~25%–34%)**: Shifts to test-driven development (TDD), explaining the Red/Green/Refactor cycle and how to write tests that lead to simple, working code. Emphasizes tolerating duplication over anticipating the wrong abstraction, and shows how to expose responsibilities through careful API design. - **Middle (~34%–47%)**: Covers the practical mechanics of building a test suite for the song's verses and the full song, including how to avoid "echo-chamber" tests that merely mirror the implementation. Introduces the idea that requirements will change, setting up the need for refactoring. - **Middle (~47%–end of excerpts)**: Begins the "Unearthing Concepts" phase, where a new requirement triggers a systematic, incremental refactoring process. Introduces simple rules that allow complex behavior to emerge, revealing hidden concepts in the code and preparing for the removal of conditionals (Chapter 6) and the exploration of factories (Chapter 7). 【Key Takeaways】 - **The right abstraction is found, not predicted** (Early): Resist creating abstractions until the code demands them; premature abstractions are often wrong and create a catch-22 where the wrong abstraction prevents you from understanding the code well enough to fix it. - **Name methods for their meaning, not their implementation** (Early): Naming a method `beer()` because it returns "beer" couples the name to current details; naming it `beverage()` isolates the code from future changes like switching to "Kool-Aid," making the code more resilient. - **Use metrics as crowd-sourced opinions, not absolute truth** (Early): Metrics like Cyclomatic Complexity and ABC size provide objective, comparable measures of code quality, helping you make design decisions based on facts rather than subjective taste. - **"Shameless Green" optimizes for understandability over changeability** (Early): The simplest working solution that passes tests is the best starting point; it tolerates duplication and avoids speculative abstraction, allowing future requirements to reveal the correct design. - **TDD's guiding principle: "Quick green excuses all sins"** (Early): When unsure of the next test or refactoring step, adopt Kent Beck's mantra to get to green quickly, then refactor incrementally with confidence that tests will catch regressions. - **Tolerate duplication to reveal the abstraction** (Early): Squeezing out all duplication at the end of every test is unnecessary; waiting for more information from subsequent tests or requirements helps you find the right abstraction instead of guessing wrong. - **Design the public API deliberately** (Middle): When exposing methods like `verses(hi, lo)`, make intentional decisions about argument order and inclusivity (e.g., higher number first, inclusive range) to create a clear, intuitive interface for callers. - **Avoid echo-chamber tests that mirror implementation** (Middle): Tests that simply replicate the code's logic (e.g., using `downTo` to build expected output) don't verify behavior; they just re-state the implementation, failing to catch real bugs. 【Reading Tips】 - **Do the exercise first**: The authors strongly advise solving the 99 Bottles problem yourself before reading the solutions; your ideas will be "contaminated" otherwise, and you'll miss the learning value of comparing approaches. - **Skim the code listings, but study the explanations**: The book is code-heavy; focus on the prose that explains *why* each solution is better or worse, rather than getting lost in syntax details. - **Deep-read the metrics discussion (Early)**: The sections on Cyclomatic Complexity and ABC size are foundational for evaluating code objectively; understanding these will help you judge the later refactoring decisions. - **Pay attention to the TDD chapters (Early–Middle)**: The Red/Green/Refactor cycle and the test-writing strategies are practical skills you can apply immediately; take notes on how to choose the next test and when to refactor. - **Watch for the "Unearthing Concepts" transition (Middle)**: This is where the book shifts from writing simple code to systematically improving it; the rules introduced here are the key to the later chapters on removing conditionals and building factories. 【Coverage Limits】 The excerpts cover the book's opening through the early-middle chapters (roughly 0–47%), focusing on problem framing, code evaluation, TDD, and the beginning of refactoring. Later chapters on removing conditionals, factories, and programming aesthetics are mentioned but not detailed in this guide.