Philosophy of Software Design — Complexity as the Thing Being Managed

• · P1 — Complexity is whatever makes a system hard to understand or change. Not line count, not cleverness, not the number of files. If a competent newcomer can't work out where to make a change and what it will break, the system is complex — regardless of how tidy it looks.
• · P2 — Complexity shows up as three symptoms, and each is diagnosable. *Change amplification*: a conceptually small change touches many places. *Cognitive load*: how much a developer must hold in their head to work here. *Unknown unknowns*: it isn't even clear what must be changed, which is the worst of the three because no amount of reading the call site reveals it.
• · P3 — Complexity has exactly two causes: dependencies and obscurity. A dependency is when code cannot be understood or changed in isolation. Obscurity is when important information isn't apparent. Every technique in this pack reduces one or the other, and a technique that reduces neither is decoration.
• · P4 — Complexity is incremental, which is why it wins. No single change makes a system unmaintainable; a thousand small acceptable ones do. It follows that there is no threshold below which a mess is too small to matter — the tolerance itself is the mechanism.
• · P5 — A module's value is its functionality divided by its interface. *Deep*: simple interface, substantial behavior behind it. *Shallow*: an interface nearly as complicated as the implementation it hides, so the caller pays the full cost of the abstraction and receives almost nothing.

• · Ask what the caller stops needing to know. It is the fastest test for whether a boundary is real, and it works on interfaces, classes, services, and files alike.
• · When tempted to split, write the new unit's interface comment first. If it's awkward to write, the boundary is wrong. Two minutes here saves the refactor.
• · Prefer one longer unit with a clear interface to three short ones sharing state. Exception: a testing seam, or a piece with a genuinely different reason to change.
• · Count how many places a change touched, and treat a high number as a design report. Change amplification is the most measurable of the three complexity symptoms — the diff tells you directly.
• · When two modules both know a format, one of them is wrong. Usually the one that acquired the knowledge second, informally, because it was convenient.

• · Ver anti-patrones específicos del dominio en el pack.

• [ ] Every module or class can be described in one sentence naming what it hides. (PSD1)
• [ ] No public interface exposes nearly as many concepts as its implementation. (PSD2)
• [ ] Each new class or module introduced by this change states what it hides. (PSD3)
• [ ] The same design decision — format, encoding, key layout, retry policy — is known to exactly one module. (PSD8)
• [ ] Modules are grouped by what they know, not by the order work happens in. (PSD9)
• [ ] No public field, getter, or setter exposes an implementation choice. (PSD10)

• A Philosophy of Software Design

Este pack cita las siguientes fuentes registradas en el índice bibliográfico:

• webA Philosophy of Software DesignJohn Ousterhout. Yaknyam Press