Tidy First A Personal Exercise in Empirical Software Design (Kent Beck)（Z-Library）

【One-Line Pitch】 A practical, philosophy-driven guide to improving code readability through small, safe structural changes ("tidyings") before or after behavior changes, ideal for working programmers who want to make large changes incrementally without a heavy design process. 【Book Arc】 - **Opening (~0%–9%)**: Introduces the core problem—messy code hinders change—and the central concept of "tidying" as small structural improvements. The foreword establishes the theoretical foundation: coupling and cohesion as measures of human comprehension, not machine efficiency. - **Early (~9%–25%)**: Lays out the first set of concrete tidyings, starting with guard clauses and dead code removal. Emphasizes the "tiny steps" principle and introduces the empirical design stance: design when you can take advantage of it, not speculatively or reactively. - **Early–Middle (~25%–38%)**: Continues the catalog of tidyings—new interface/old implementation, reading order, cohesion order, explaining variables/constants, explicit parameters. Each is presented as a micro-decision that reduces cognitive load and prepares code for change. - **Middle (~38%–47%)**: Covers chunking statements and the counterintuitive "mooshing" (lumping code together) when small pieces create confusion. Introduces the crucial distinction between behavior changes (B) and structure changes (S), and the practice of separating them into different PRs. - **Late (~47%+)**: Synthesizes the tidyings into sequences and flows, showing how small structural moves compound into easier behavior changes. The book closes by framing software design as an exercise in human relationships and judgment, not just technique. 【Key Takeaways】 - **Tidying is structural, not behavioral** (Early): A tidying changes how code looks and reads but never what it does. This distinction lets you make safe, reversible improvements without risking functionality—separate tidying commits from behavior-change commits. - **Coupling and cohesion are about human brains, not machines** (Opening): Code is easier to understand when related pieces hang together (cohesion) and when connections between pieces are few and weak (coupling). This is the theoretical lens for all tidyings. - **Design timing is empirical, not speculative** (Early): Design "somewhere in the middle"—when you observe a class of features is hard to add, design until the pressure is relieved. This requires taste and judgment, not rigid rules. - **Tiny steps compound** (Early): Always take small, safe steps. A guard clause or a blank line may seem trivial, but software design enables more software design—compound interest works for code structure too. - **Reading order is a gift to the next reader** (Early): Reorder code in the sequence a reader would prefer to encounter it. You are the reader; use your recent experience to decide. Don't mix other tidyings into the same pass. - **Cohesion order beats decoupling when decoupling is too costly** (Early): If you can't eliminate coupling (intellectual, time, or relationship constraints), at least move coupled elements adjacent. This makes behavior changes easier without a big refactor. - **Explicit parameters improve testability and clarity** (Middle): Split routines to pass data explicitly rather than via maps or environment variables. This makes code easier to read, test, and analyze—and prepares it for future changes. - **Separate tidying from behavior in version control** (Middle): Put tidyings in one PR and behavior changes in another. Reviewers will balk at mixed changes; separating them makes each review clearer and each change safer. 【Reading Tips】 - **Skim the table of contents and pick tidyings relevant to your current pain** (Early): The book is designed for non-linear reading—try a few examples that match your problem rather than reading cover-to-cover. - **Deep-read the theory sections (foreword, preface, and Part II)**: These explain *why* tidying works (coupling, cohesion, empirical design) and are essential for internalizing the approach, not just copying techniques. - **Practice each tidying on real code as you read**: The examples are simple, but the value comes from applying them. Start with guard clauses and chunking statements—the easiest wins. - **Watch for the "mooshing" counterintuitive move** (Middle): When small pieces create confusion, lumping code together is legitimate. Don't skip this chapter; it prevents dogmatic over-splitting. - **Take away the PR-separation habit** (Middle): Even if you don't adopt all tidyings, separating structural from behavioral changes in version control is a universally valuable practice. 【Coverage Limits】 The excerpts cover the tidyings catalog and the early theory, but do not include the full Part II discussion of sequences, coupling power laws, or the later chapters on human relationships and economics (discounted cash flows, optionality). The guide focuses on the practical tidyings and the behavior/structure distinction.