Clean Code

Contents

• Part 01 · Principles, Patterns & Practices
  01Clean Code
  02Meaningful Names
  03Functions
  04Comments
  05Formatting
  06Objects and Data Structures
  07Error Handling
  08Boundaries
  09Unit Tests
  10Classes
  11Systems
  12Emergence
• Part 02 · Case Studies in Cleaning Code
  13Concurrency
  14Successive Refinement
  15JUnit Internals
  16Refactoring SerialDate
• Part 03 · Smells & Heuristics
  17Smells and Heuristics

Clean Code

Bad code slows teams exponentially until productivity collapses and a doomed "Grand Redesign" begins. Clean code is a professional and moral responsibility of programmers, not managers, and demands both knowledge of principles and the discipline to apply them.

Total Cost of Owning a Mess

As mess accumulates, team productivity asymptotically approaches zero. Adding developers makes it worse — new hires add changes without understanding the original design, deepening the chaos.

The Grand Redesign in the Sky

When code becomes unmaintainable, teams demand a rewrite. A tiger team chases a moving target while the maintenance team keeps shipping, and the new system usually arrives years late with the same problems.

The Boy Scout Rule

"Leave the campground cleaner than you found it." Every check-in should improve the code slightly. Continuous incremental cleanup fights entropy where heroic rewrites fail.

Code Reads Like Prose

Per Grady Booch, clean code reads like well-written prose with crisp abstractions and straightforward control flow that never obscures the designer's intent.

Does One Thing Well

Per Bjarne Stroustrup, clean code is focused — each module, function, and class is dedicated to a single purpose, uncorrupted by surrounding details.

We Are Authors

The ratio of reading code to writing code is over 10:1. Programmers are authors writing for other programmers, so making code easy to read makes it easier to write.

Craftsmanship Requires Knowledge and Work

Clean coding is a two-part discipline — knowledge of principles, patterns, and practices, plus work of practiced application until they become intuition.

Wading

Pushing through bad code to make changes; friction created by a messy codebase.

LeBlanc's Law

"Later equals never" — postponed cleanup almost never happens.

Refactoring

Restructuring code without changing external behavior to improve readability and design.

Tiger Team

An elite team commissioned to build a replacement during a Grand Redesign.

Code Sense

The aesthetic ability to recognize clean vs. dirty code and devise transformations between them.

Professionalism

The programmer's duty to defend the code against bad requirements, schedules, and managers.

Craftsmanship

A discipline requiring both theoretical knowledge and practiced application.

Multiple choice

According to Martin, what happens to team productivity as mess accumulates in a codebase?

• AIt stays roughly constant because experienced devs adapt
• BIt dips temporarily, then recovers after a refactor sprint
• CIt asymptotically approaches zero
• DIt scales linearly with team size

True / False

Adding more developers to a messy codebase generally speeds things back up.

• TrueTrue
• FalseFalse

Multiple choice

What is the Boy Scout Rule?

• AAlways pair-program on legacy code
• BLeave the code slightly cleaner than you found it on every check-in
• CRewrite any module older than 3 years
• DNever commit on Fridays

Spot the issue

A team lead says: "This codebase is unsalvageable. Let's spin up a tiger team to build the replacement while the rest of us keep the old one running. We'll cut over in 18 months." What's Martin's warning about this plan?

• ATiger teams chase a moving target and the rewrite usually arrives late with the same problems
• BTiger teams burn out faster than maintenance teams
• CEighteen months is too aggressive; rewrites need two years
• DThe maintenance team will resist the cutover

Multiple choice

Whose responsibility is it to defend code quality against bad schedules and pressure to ship a mess?

• AProject managers, since they own scope and deadlines
• BQA, since they own quality gates
• CThe customer, since the product is theirs
• DThe programmers, since they own the code

Meaningful Names

Names appear everywhere in software, so choosing them well is one of the highest-leverage activities in coding. This chapter offers concrete rules for revealing intent, avoiding disinformation, and making code self-documenting through naming.

Intention-Revealing Names

A name should answer why it exists, what it does, and how it is used. If a name needs a comment, it has failed to reveal intent — `int elapsedTimeInDays` beats `int d`.

Avoid Disinformation

Don't call something `accountList` unless it's a List. Avoid names that differ in small ways (`XYZControllerForEfficientHandlingOfStrings` vs. `...StorageOfStrings`), and never use lowercase L or uppercase O.

Make Meaningful Distinctions

Noise words like `Info`, `Data`, `the`, or `variable` add no real distinction. `ProductInfo` vs. `ProductData` tells the reader nothing useful, and number-series naming (`a1`, `a2`) is pure laziness.

Pronounceable and Searchable

Names you can pronounce enable verbal discussion. Longer searchable names beat short cryptic ones — `MAX_CLASSES_PER_STUDENT` is greppable, the literal `7` is not.

Classes Are Nouns, Methods Are Verbs

Classes should be nouns or noun phrases (`Customer`, `Account`); methods should be verbs or verb phrases (`postPayment`, `deletePage`). Use `get`/`set`/`is` accessor conventions consistently.

One Word Per Concept

Pick one word for one abstract concept and stick with it. Don't mix `fetch`, `retrieve`, and `get` across equivalent operations — consistent vocabulary is a gift to readers.

Add Meaningful Context Without Pollution

`state` means little alone but makes sense inside an `Address` class. Conversely, don't prefix every class with `GSD` for "Gas Station Deluxe" — gratuitous context pollutes auto-complete.

Intention-Revealing Name

A name whose presence communicates purpose without needing comments.

Disinformation

Misleading clues in a name — false implications about type or behavior.

Noise Word

A redundant word (`Info`, `Manager`, `the`) that fails to distinguish names.

Hungarian Notation

Encoding type info into names (`strName`); obsolete in strongly-typed languages.

Mental Mapping

The cognitive burden of translating a cryptic name into its real meaning.

Problem Domain Name

A term from the business; preferred when no clean technical analogue exists.

Solution Domain Name

A computer-science term (algorithm, pattern, math); use when fitting.

Spot the issue

What's the biggest naming problem?

const d = 86400000;
function calc(a, b) {
  return a + b * d;
}

• AVariables shadow built-ins
• B`d`, `a`, `b`, and `calc` reveal no intent — the reader must reverse-engineer the math
• CThe function should be an arrow function
• D`86400000` should be in a config file

True / False

`accountList` is a fine name for a `Set<Account>` as long as the meaning is clear from context.

• TrueTrue
• FalseFalse

Multiple choice

You have two classes: `ProductInfo` and `ProductData`. What's Martin's verdict?

• AThe names use noise words (`Info`, `Data`) and make no meaningful distinction
• BFine — `Info` clearly holds metadata while `Data` holds payload
• CAcceptable if a Javadoc comment explains the difference
• DGood — the names show separation of concerns

Multiple choice

Why does Martin prefer `MAX_CLASSES_PER_STUDENT` over the literal `7` scattered through code?

• ANamed constants are faster at runtime
• BIt satisfies a common linter rule against magic numbers
• CThe named constant is greppable — searching for `7` returns unrelated matches, the name surfaces every real use
• DNumeric literals are forbidden in OO languages

Multiple choice

A codebase uses `fetch`, `retrieve`, and `get` interchangeably for equivalent operations. What does Martin recommend?

• AKeep all three — synonyms make the code more readable
• BUse the synonym best suited to each call site's domain
• CDocument the distinction between them in a glossary comment
• DPick one word per concept and use it consistently — synonyms force readers to wonder if there's a hidden distinction

Functions

Functions are the first line of organization in any program. Martin's rules — be small, do one thing, operate at a single level of abstraction, take few arguments, avoid side effects, and prefer exceptions to error codes — make functions easy to read, test, and reuse.

Small! Smaller Than That!

Functions should be very small — ideally 20 lines or fewer. Blocks within `if`, `else`, and `while` should typically be one line, often a function call.

Do One Thing

"Functions should do one thing. They should do it well. They should do it only." A function does one thing when all statements sit at the same level of abstraction — if you can extract another meaningful function, it was doing too much.

One Level of Abstraction per Function

The Stepdown Rule says code should read top-down like a narrative. Mixing high-level policy with low-level string manipulation confuses readers — each function should be followed by those at the next level below.

Descriptive Names

Don't be afraid of long names. A long descriptive name beats a short cryptic name or a long descriptive comment. Consistent phrasing aids understanding (`includeSetupPage`, `includeSuiteSetupPage`).

Few Arguments

Niladic (zero) is best, then monadic (one), then dyadic (two). Triadic should be avoided and polyadic (4+) needs justification. Arguments are hard to read, test, and reason about.

No Side Effects

A function named `checkPassword` should only check the password. If it also initializes the session, that hidden temporal coupling is a bug waiting to happen — make side effects explicit or split the function.

Prefer Exceptions to Error Codes

Returning error codes forces callers to handle errors inline, creating deeply nested if-structures. Exceptions separate the happy path from error handling. Also: avoid duplication — DRY is the root of clean code.

Stepdown Rule

Code reads top-down — each function followed by those one level lower in abstraction.

Level of Abstraction

Conceptual distance from raw implementation.

Arity

Number of arguments (niladic = 0, monadic = 1, dyadic = 2, triadic = 3, polyadic = 4+).

Flag Argument

A boolean parameter signaling "do A or B" — proves the function does more than one thing.

Output Argument

A parameter the function mutates as a return mechanism; replace with return values.

Command Query Separation

A function should either do something or answer something, never both.

DRY

Don't Repeat Yourself — every piece of knowledge should have one unambiguous representation.

Spot the issue

Which Clean Code rule is most clearly violated?

function processOrder(order, sendEmail) {
  validate(order);
  db.save(order);
  if (sendEmail) {
    mailer.send(order.customerEmail);
  }
  return order.id;
}

• AThe function name is too long
• B`sendEmail` is a flag argument — the function clearly does more than one thing
• CIt should be async
• DThe return value is the wrong type

Multiple choice

What does "one level of abstraction per function" mean in practice?

• AEach function should contain exactly one statement
• BFunctions should only call other functions, never raw expressions
• CAll statements in a function should sit at the same conceptual distance from the raw implementation
• DA function should use only primitive types, no domain objects

True / False

A function called `checkPassword` is allowed to initialize the user's session as long as it's documented.

• TrueTrue
• FalseFalse

Multiple choice

Why does Martin prefer throwing exceptions over returning error codes?

• AExceptions execute faster than `if`-checks at runtime
• BError codes cannot represent every possible failure mode
• CExceptions log themselves automatically
• DThey keep the happy path linear and push error handling out of the main flow

Spot the issue

Martin would flag what about this function?

function writeField(record, name) {
  record.write(name);
}

• A`record` is mutated — it's an output argument and the relationship isn't obvious from the call site
• BThe function is too short
• C`name` should be typed
• DMissing error handling

Comments

Comments are at best a necessary evil — they compensate for our failure to express intent in code. Most comments lie, rot, or duplicate the code; this chapter inventories the few good kinds and the many bad kinds.

Comments Don't Make Up for Bad Code

"Don't comment bad code — rewrite it." A tangled module with explanatory comments should be cleaned up, not annotated. Clear code rarely needs commentary.

Explain Yourself in Code

Instead of `// Check to see if the employee is eligible for full benefits`, extract a function `employee.isEligibleForFullBenefits()`. The code itself can usually express intent.

Good Comments Are Rare but Real

Acceptable categories: legal (copyright), informative (regex format), explanation of intent, clarification of opaque library returns, warning of consequences, TODO, amplification, and Javadocs in public APIs.

Bad Comments Dominate in Practice

Most comments are mumbling, redundant, misleading, mandated (forced Javadoc), journal entries, or noise (`/** Default constructor. */`). All add clutter without insight.

Prefer Functions and Variables to Comments

A complex boolean like `if ((module.getDependSubsystems().contains(subSysMod.getSubSystem())))` deserves a well-named intermediate variable or extracted function, not a comment explaining what it does.

Avoid Banners and Closing-Brace Notes

Banners (`/////// Actions ///////`), attributions (`/* Added by Rick */`), and `} // end while` notes signal that your functions are too long. Shrink them so structure is obvious.

Never Leave Commented-Out Code

Other developers won't dare delete it because they assume it's important. Modern source control remembers history — just delete it.

Javadoc

Java's structured comment format for API docs; valuable for public APIs, abused as mandated noise.

TODO Comment

A note for work that should be done; should be scanned and cleared regularly.

Legal Comment

Required copyright/license notices at the top of source files.

Informative Comment

Conveys basic info (regex format) that can't be expressed in code.

Mandated Comment

Required by rule, producing forced low-value boilerplate.

Journal Comment

A running log of edits at the top of a module; obsolete with source control.

Noise Comment

Adds no new information beyond what the code already says.

Spot the issue

What does Martin recommend instead?

// Check to see if the employee is eligible for full benefits
if (employee.flags & HOURLY_FLAG && employee.age > 65) {
  // ...
}

• AKeep the comment — it accurately describes the condition
• BReplace the comment with a longer, more detailed comment block
• CExtract the boolean into a function like `employee.isEligibleForFullBenefits()`
• DMove the comment inside the `if` block

Multiple choice

A teammate sees a tangled module and adds detailed comments to explain how it works. What's Martin's verdict?

• AGood — future readers will thank them
• BDon't comment bad code, rewrite it
• CAcceptable if the comments include diagrams
• DFine as long as the comments are kept up to date

True / False

Leaving commented-out code in place is helpful because other developers can re-enable it if needed.

• TrueTrue
• FalseFalse

Spot the issue

What's the smell?

/////////////// Actions ///////////////
function save() { /* ... */ }
function load() { /* ... */ }

function process() {
  // ... many lines ...
} // end process

• ABanner comments and closing-brace notes signal the functions are too long
• BThe functions are missing JSDoc
• CThe banner should use a different character
• DThe functions should be in alphabetical order

Formatting

Code formatting is about communication, and communication is a professional developer's first order of business. Martin distinguishes vertical formatting (file size, the Newspaper Metaphor) from horizontal formatting (line width, spacing), and urges teams to agree on one style.

The Newspaper Metaphor

A source file should read like a newspaper article — headline at the top, high-level summary first, growing in detail toward the bottom. Readers should be able to stop once they have enough.

Vertical Openness Between Concepts

Blank lines separate packages, imports, and groups of methods — visual cues marking new concepts. Without them, code blurs together.

Vertical Density Implies Association

Tightly related lines should appear vertically dense (no blank lines, no comments between them) so the eye groups them as one thought.

Vertical Distance and Dependent Functions

Variables go near their use, instance variables at the top of the class. A function that calls another should be placed above the one it calls — top-down readability.

Horizontal Formatting

Lines should be 80–120 characters. Wider lines force horizontal scrolling and show carelessness. Use whitespace to group strongly related things and separate weakly related ones.

Indentation Makes Hierarchy Visible

Indentation reveals scope hierarchy. Even one-line `if` or `while` bodies should be properly indented and braced — the structure aids scanning.

Team Rules

A team should agree on a single formatting style. The codebase should look like it was written by one person, not a clashing rabble — consistency is the goal.

Vertical Formatting

Arrangement of code down the page — file size, blank lines, method ordering.

Horizontal Formatting

Arrangement across the page — line width, indentation, operator spacing.

Newspaper Metaphor

Files organized like news articles — title, summary, then progressive detail.

Vertical Openness

Blank lines that visually separate distinct concepts.

Vertical Density

Lack of whitespace between related lines to mark them as one thought.

Variable Declaration Locality

Declaring variables as close as possible to their usage.

Conceptual Affinity

Similar functions (overloads, related methods) placed near each other.

Multiple choice

What is the Newspaper Metaphor?

• AFiles should read top-down — high-level summary first, growing in detail downward
• BFiles should be printed and reviewed on paper before commit
• CFiles should be split into multi-column layouts
• DFiles should be no longer than a newspaper column

Spot the issue

What violates Martin's vertical-distance guideline?

function postPayment() { /* ... */ }
function loadHtml() { /* ... */ }
function calculateTax() { /* ... */ }
function postPayment2() { /* ... */ }

• AFunction names are too short
• BThe file simply has too many functions for one module
• CConceptually affine functions (`postPayment` and `postPayment2`) are separated by unrelated functions
• DFunctions should be sorted alphabetically

True / False

A team should let each developer pick their own formatting style — variety keeps the code interesting.

• TrueTrue
• FalseFalse

Multiple choice

Why does Martin care about lines being roughly 80-120 characters wide?

• AOlder terminals can't display more
• BWider lines force horizontal scrolling and suggest carelessness
• CCompilers run faster on shorter lines
• DIt's required by most language specs

Objects and Data Structures

This chapter explores the deep tension between objects (hide data, expose behavior) and data structures (expose data, no behavior). Martin shows these are opposites — each makes the other's hard problems easy — and offers the Law of Demeter as a rule of thumb.

Data Abstraction

Hiding implementation is about abstractions, not just getters and setters. A `Vehicle` interface should expose `getPercentFuelRemaining()` — an abstract concept — rather than `getFuelTankCapacityInGallons()` and `getGallonsOfGasoline()`.

Data/Object Anti-Symmetry

Objects hide data behind abstractions and expose functions; data structures expose data and have no meaningful functions. They are virtual opposites and serve opposite purposes.

The Procedural/OO Trade-Off

Procedural code makes it easy to add new functions without changing data structures, but hard to add new data types. OO code is the reverse — easy to add new classes, hard to add new functions (every class must change).

The Law of Demeter

A method `f` of class `C` should only call methods of `C`, objects it creates, objects passed as arguments, or objects held in instance variables. Don't talk to strangers — only to immediate friends.

Train Wrecks

Chains like `ctxt.getOptions().getScratchDir().getAbsolutePath()` are a smell — they couple the caller to navigation structure of multiple objects. Whether they violate Demeter depends on whether the intermediates are objects or data structures.

Hybrids Are the Worst of Both

A class with both public accessors and business methods makes it hard to add new functions and hard to add new data structures — a sign of muddled design that should be split.

Data Transfer Objects

Pure data structures with public variables and no functions are appropriate at system boundaries — database rows, network messages. Their lack of behavior is a feature.

Object

An entity that hides data behind abstractions and exposes functions; favored when adding new types.

Data Structure

An entity that exposes data and has no meaningful behavior; favored when adding new operations.

Law of Demeter

A method should not know about the innards of objects it manipulates.

Train Wreck

A chain `a.getB().getC().doSomething()` dragging the caller through multiple structure layers.

Feature Envy

A method more interested in another class's data than its own.

Hybrid

A class mixing real behavior with public accessors — disadvantages of both styles.

DTO

Data Transfer Object — public fields, no functions; used to move data between layers.

Active Record

A DTO with navigational methods like `save` and `find`; keep business logic out.

Spot the issue

What does Martin call this and why?

const path = ctxt.getOptions().getScratchDir().getAbsolutePath();

• AA fluent interface — preferred style
• BA train wreck — couples the caller to the navigation structure of multiple objects
• CA pipeline — neutral
• DA builder pattern call

Multiple choice

According to Martin, what is the procedural/OO trade-off?

• AOO is always cleaner than procedural for any system
• BProcedural runs faster but is harder to test
• CProcedural makes adding new functions easy and new types hard; OO is the reverse
• DThey produce identical designs in practice

Multiple choice

Per the Law of Demeter, a method should talk only to:

• AAny object reachable from its arguments via getter chains
• BSingletons and static utilities in the same module
• CAnything declared in the same package
• DIts own class, objects it creates, arguments, and held instance variables — not strangers

True / False

A class with both public getters/setters and business methods is a clean compromise between objects and data structures.

• TrueTrue
• FalseFalse

Error Handling

Error handling is important, but if it obscures logic, it's wrong. Clean code requires error handling be a separate concern, viewable independently of the main logic. Martin advocates exceptions over return codes, structured try-catch-finally, and code that doesn't force callers to manage errors inline.

Use Exceptions Rather Than Return Codes

Return codes clutter callers with immediate checks that obscure logic. Throwing exceptions separates the happy path from error handling cleanly.

Write Your Try-Catch-Finally First

Treat try blocks like transactions. Starting with try-catch-finally helps define the scope and expected behavior, making it easier to maintain invariants when exceptions occur.

Use Unchecked Exceptions

Checked exceptions violate the Open/Closed Principle — a change deep in the call stack forces signature changes all the way up, breaking encapsulation.

Provide Context with Exceptions

Every exception should include enough informational context — operation, failure type, source — so the error message reveals intent without needing a stack trace dive.

Define Exception Classes by Caller's Needs

Classify exceptions by how they will be caught, not by source. Often a single exception class wrapping a third-party API is enough.

Special Case Pattern

Instead of sprinkling null checks or try/catches, create an object that handles the special case so client code stays simple. A null object is the canonical example.

Don't Return Null, Don't Pass Null

Returning null creates work for callers and invites NullPointerExceptions. Passing null into methods is worse — prohibit it by default and use exceptions or empty collections instead.

Checked Exception

Must be declared or caught; enforced by the compiler (Java-specific).

Unchecked Exception

A runtime exception; preserves encapsulation across call layers.

Special Case Pattern

A class encapsulating exceptional behavior so client code stays simple.

Wrapper

A class that wraps an external library to consolidate its many exceptions into one.

Happy Path

The normal expected execution flow, uncluttered by error handling.

Null Object

An object providing default behavior in place of a null reference.

SRP for Errors

Error handling is one thing; a function that handles errors should do nothing else.

Spot the issue

What's the problem Martin would flag?

function getUser(id) {
  const user = db.find(id);
  if (user === null) return null;
  return user;
}
// caller:
const u = getUser(42);
u.name; // boom

• AThe function should be async
• BReturning null pushes work onto callers and invites NullPointerExceptions
• C`find` should be named `query`
• DThe function should log the lookup

Multiple choice

Why does Martin recommend writing the try-catch-finally block first?

• AJava requires the try-catch-finally to be declared before the try body
• BIt satisfies the type checker earlier in the edit cycle
• CTreating try blocks like transactions defines the scope and expected behavior up front
• DWriting the happy path first is measurably slower

Multiple choice

Martin's preferred way to classify exception classes is by:

• AThe library or layer that throws them
• BWhether they are checked or unchecked
• CSeverity level (warning, error, fatal)
• DHow callers will catch and handle them

True / False

Checked exceptions are clean code's preferred error mechanism in modern Java.

• TrueTrue
• FalseFalse

Boundaries

This chapter addresses how to integrate foreign code — third-party libraries, other teams' APIs, code yet-to-be-written — into your system cleanly. Martin recommends isolating boundaries behind interfaces you control, writing learning tests, and treating boundaries as seams of change.

Using Third-Party Code

There's natural tension between providers (who want broad applicability) and users (who want focused interfaces). Avoid passing raw third-party types like `Map` across system boundaries.

Exploring and Learning Boundaries

Rather than learn a new library by reading docs and integrating simultaneously, write learning tests that exercise the API in isolation to understand its behavior.

Learning Tests Are Better Than Free

Learning tests verify your understanding of third-party code and act as a regression suite when new versions arrive — catching breaking changes before users do.

Using Code That Does Not Yet Exist

When integrating with an unfinished API, define your own interface representing what you wish existed. Later, write an Adapter to bridge the gap.

Clean Boundaries

Code at boundaries needs clear separation and tests that define expectations. Depend on something you control, not something you don't.

Encapsulating Boundary Interfaces

Wrap third-party APIs (e.g., `Map<String, Sensor>`) inside a domain class so generic collection types don't leak through your codebase.

Adapter Pattern at Boundaries

Use Adapters to convert between your ideal interface and the actual third-party or future interface, isolating change to a single conversion point.

Boundary

The seam where your code meets foreign code.

Learning Test

A test you write to explore a third-party API; doubles as upgrade regression check.

Adapter Pattern

Converts the interface of a class into another interface clients expect.

Encapsulation Boundary

A wrapping class hiding a third-party type behind your own operations.

Seam

A place where you can alter behavior without editing in that place.

Foreign Code

Code outside your control — libraries, frameworks, other teams' modules.

FAKE Interface

An interface for code that doesn't yet exist, letting work proceed and be tested.

Spot the issue

The raw `Map<String, Sensor>` is passed everywhere. What's the smell?

// in many places throughout the system:
function readSensors(sensorMap) {
  for (const id of Object.keys(sensorMap)) {
    // ...
  }
}

• AMaps are slow at runtime
• BThe generic collection type leaks across boundaries — wrap it in a domain class
• CThe keys should be integers
• D`for...of` is the wrong loop

Multiple choice

What is a "learning test" and why does Martin recommend writing one?

• AA test you write first, before any production code, to drive design (i.e., TDD)
• BA test demonstrating TDD principles to junior developers
• CA small test that exercises a third-party API in isolation to learn how it behaves
• DA throwaway script for performance benchmarking the new library

Multiple choice

You need to integrate with an API that another team hasn't finished. What does Martin recommend?

• ABlock your team until they ship a stable version
• BCouple directly to their current draft and adjust as it changes
• CInline mock stubs of their API throughout your production code
• DDefine your own interface representing what you wish existed, then bridge later with an Adapter

True / False

Learning tests are a cost — they take time away from real work.

• TrueTrue
• FalseFalse

Unit Tests

Martin argues that test code is just as important as production code. He introduces the Three Laws of TDD, the F.I.R.S.T. principles, and the BUILD-OPERATE-CHECK structure, insisting that without clean tests you lose the ability to change production code safely.

The Three Laws of TDD

(1) Don't write production code until you have a failing unit test. (2) Don't write more of a test than is sufficient to fail. (3) Don't write more production code than is sufficient to pass.

Keeping Tests Clean

Dirty tests are worse than no tests. As production code changes, dirty tests become hard to maintain and eventually get discarded — taking your safety net with them.

Tests Enable the -ilities

Clean tests make flexibility, maintainability, and reusability possible. Without them, every change to production code is risky and developers freeze.

One Concept Per Test

Tests should ideally verify one concept per function. Multiple asserts are OK if they verify the same concept, but avoid testing unrelated behaviors in one test.

BUILD-OPERATE-CHECK

Tests should have three clear parts: build the test data, operate on it, check the result. Also known as Arrange-Act-Assert.

Domain-Specific Testing Language

Build a specialized API layer for your tests so they read at a higher level of abstraction, hiding setup noise from the reader.

F.I.R.S.T.

Tests should be Fast, Independent, Repeatable, Self-Validating, and Timely. Slow tests don't run; dependent tests cascade failures; manual checks don't scale.

TDD

Writing failing tests before production code, governed by the Three Laws.

F.I.R.S.T.

Fast, Independent, Repeatable, Self-Validating, Timely.

BUILD-OPERATE-CHECK

Three-part test structure equivalent to Arrange-Act-Assert.

Single Concept per Test

Each test verifies one idea, keeping diagnostics high when it fails.

Self-Validating

Tests produce a pass/fail boolean; no manual log inspection.

Domain-Specific Testing API

Helpers that let tests speak in domain terms.

Test Regression Suite

The collected tests protecting against unintended changes.

Multiple choice

What does the "I" in F.I.R.S.T. stand for, and why does Martin care?

• AIdempotent — running a test twice gives the same result
• BIntegrated — tests must exercise real downstream services
• CIndependent — tests must not depend on each other or cascade failures
• DInstrumented — tests must collect coverage metrics

True / False

Dirty tests are still better than no tests at all.

• TrueTrue
• FalseFalse

Spot the issue

What clean-tests rule does this violate?

test('user flow', () => {
  const u = createUser('a@b.com');
  expect(u.email).toBe('a@b.com');
  loginUser(u, 'pw');
  expect(session.isActive).toBe(true);
  deleteUser(u);
  expect(db.find(u.id)).toBeNull();
});

• ATests should not use `expect`
• BOne concept per test — this verifies three unrelated behaviors in one function
• CTest files should not import production code
• DThe arrange phase is missing

Multiple choice

The Three Laws of TDD impose what discipline?

• AAlways pair-program when writing tests
• BAlways test every private method exhaustively
• CAlways write tests after the feature code is complete
• DDon't write production code without a failing test; don't over-write either tests or code

Classes

Classes should be small, organized with a standard convention, and adhere to the Single Responsibility Principle. Martin measures classes not by lines but by responsibilities, and argues good design supports both cohesion and the ability to change without ripple effects.

Class Organization

Standard order: public static constants, then private static variables, then private instance variables, then public methods, with private helpers immediately following the public method that uses them.

Classes Should Be Small

Size is measured by responsibilities, not lines. If you can't name the class in ~25 words without "if/and/or/but," it has too many responsibilities.

Single Responsibility Principle

A class should have one reason to change. Identifying responsibilities is one of the most fundamental concepts of design — and most often violated.

Cohesion

A class is cohesive when its methods and variables are co-dependent and form a logical whole. When cohesion drops, splitting into smaller classes is warranted.

Many Small Classes Emerge from Refactoring

Breaking large functions into small ones often surfaces hidden classes. Promote variables to instance variables, then extract the cohesive subset into a new class.

Organizing for Change

Structure classes so changes are isolated. New features should be added by extending (new subclasses or classes), not by modifying existing code — the Open/Closed Principle.

Isolate from Change via DIP

Depend on abstractions, not concretions. The Dependency Inversion Principle lets you swap implementations — a test stub for a real API — without modifying client code.

SRP

Single Responsibility Principle — one reason to change.

Cohesion

Degree to which methods and variables of a class belong together logically.

OCP

Open/Closed Principle — open for extension, closed for modification.

DIP

Dependency Inversion Principle — depend on abstractions, not concretions.

Stepdown Rule

Code reads top-to-bottom from higher to lower abstraction.

Encapsulation

Hiding implementation details; loosen only as much as testing requires.

Responsibility

A reason for a class to change; counting reveals SRP violations.

Multiple choice

How does Martin measure whether a class is "small"?

• ABy counting responsibilities — one reason to change
• BLines of code under 100
• CBy cyclomatic complexity per method
• DBy the number of public methods

Spot the issue

What design rule is most clearly violated?

class ReportService {
  fetchSalesData() { /* ... */ }
  formatPdf() { /* ... */ }
  sendEmail() { /* ... */ }
  cacheToRedis() { /* ... */ }
}

• AClass is too long
• BSingle Responsibility Principle — this class has at least four reasons to change
• CClass name is too short
• DMethods should be static

True / False

The Open/Closed Principle says you should rewrite existing classes whenever you add a feature.

• TrueTrue
• FalseFalse

Multiple choice

What is the Dependency Inversion Principle's main payoff?

• AFaster runtime
• BSmaller binaries
• CYou can swap implementations (e.g., real API for a test stub) without modifying client code
• DBetter type checking

Systems

This chapter scales clean-code principles from classes to system architecture. The central theme is separating construction from use — application startup and wiring should be isolated from runtime logic. Martin advocates Dependency Injection, AOP, and incremental architecture that grows with the system.

Separate Construction from Use

Startup is a distinct concern. Segregate the construction process (wiring dependencies) from the runtime logic that uses them, often via a Main partition.

Dependency Injection

Move construction responsibility out of objects via Inversion of Control. Objects don't create their dependencies — they receive them, enabling testing and flexibility.

Scaling Up Incrementally

It is a myth that we can get systems right the first time. Clean systems are incrementally grown as new concerns surface, much like cities grow organically.

Cross-Cutting Concerns

Concerns like persistence, transactions, security, and logging cut across many objects. AOP modularizes these so they don't pollute domain code.

Java Proxies and Frameworks

Pure Java provides dynamic proxies for simple AOP. Frameworks like Spring or JBoss provide richer aspect support, letting POJOs remain pure domain objects.

Test-Drive the Architecture

Architecture can evolve through tests. Defer decisions on persistence, messaging, and frameworks until clearly needed — the Last Responsible Moment.

Use Standards When They Add Value

Don't adopt frameworks reflexively. Ensure they solve actual problems rather than being adopted for resume-building or fashion.

Dependency Injection

An object's dependencies are supplied externally, not constructed internally.

Inversion of Control

The framework calls into your code; DI is one form.

Cross-Cutting Concern

A concern (logging, security) affecting many parts of a system.

AOP

Aspect-Oriented Programming — modularizes cross-cutting concerns via aspects.

POJO

Plain Old Java Object; free of framework dependencies, the ideal domain carrier.

Main Partition

The startup module responsible for constructing and wiring objects.

Domain-Specific Language

A specialized language letting policies be expressed at the domain's abstraction level.

Multiple choice

Martin's main system-level theme is to separate:

• AFront-end concerns from back-end concerns
• BSynchronous code from asynchronous code
• CConstruction (wiring dependencies) from use (runtime logic)
• DRead paths from write paths

Spot the issue

What's the design problem?

class OrderProcessor {
  constructor() {
    this.db = new MySqlDatabase();
    this.mailer = new SmtpMailer('smtp.example.com');
  }
}

• AClass name is too generic
• BThe object constructs its own dependencies, making it hard to test and swap implementations
• CConstructors can't have side effects
• DMySQL is the wrong database

True / False

A clean system architecture must be designed up front, before any code is written.

• TrueTrue
• FalseFalse

Multiple choice

What is AOP's role in a clean system?

• AIt replaces unit testing for cross-cutting code
• BIt compiles domain objects directly to bytecode
• CIt is a wholesale replacement for object-oriented design
• DIt modularizes cross-cutting concerns (logging, security, transactions) so they don't pollute domain code

Emergence

Citing Kent Beck's four rules of Simple Design, Martin argues good design emerges from disciplined application of a small set of rules. The rules in priority order — runs all tests, no duplication, expresses intent, minimal classes/methods — yield SOLID design qualities without big upfront architecture.

Emergent Design

Beck's four rules of Simple Design (in priority order) drive design quality to emerge from refactoring, not from upfront planning.

Rule 1 — Runs All the Tests

A system that cannot be verified must not be deployed. Making code testable forces small, single-purpose classes with low coupling — which drives better design.

Rule 2 — No Duplication

Duplication is the primary enemy of a well-designed system. Eliminating it — via Extract Method, Template Method — increases clarity and reuse.

Rule 3 — Expressive Code

Code should clearly express the author's intent through good names, small functions, standard nomenclature (design patterns), and well-written unit tests.

Rule 4 — Minimal Classes and Methods

Don't be dogmatic about creating tiny classes for everything. The goal is the smallest practical set that still honors the other three rules.

Refactoring as the Vehicle

Emergent design is enabled by continuous refactoring under the safety of tests, applying the four rules incrementally after each pass.

Patterns Make Code Expressive

Using standard design pattern names (Command, Visitor, etc.) communicates intent and structure to other developers far more efficiently than ad-hoc code.

Emergent Design

Design quality arising from continuous application of simple rules and refactoring.

Simple Design

Beck's four rules — runs tests, no duplication, expresses intent, minimal classes/methods.

Refactoring

Restructuring code without changing external behavior, made safe by tests.

Template Method

A pattern removing higher-level duplication by deferring steps to subclasses.

Extract Method

A refactoring move pulling duplicated or complex code into a new named function.

Expressiveness

The property of code that reveals purpose clearly to readers.

SOLID

SRP, OCP, LSP, ISP, DIP — emerge naturally from following the four rules.

Multiple choice

What is the priority order of Beck's four rules of Simple Design?

• ARuns tests, no duplication, expresses intent, minimal classes/methods
• BExpresses intent, no duplication, runs tests, minimal classes/methods
• CNo duplication, runs tests, minimal classes/methods, expresses intent
• DMinimal classes/methods, expresses intent, no duplication, runs tests

True / False

Following Beck's four rules requires you to use the SOLID principles explicitly.

• TrueTrue
• FalseFalse

Spot the issue

Which rule of Simple Design is violated?

function totalA(items) {
  let s = 0; for (const i of items) s += i.price * i.qty; return s;
}
function totalB(cart) {
  let s = 0; for (const i of cart.lines) s += i.price * i.qty; return s;
}

• ARule 1 — Runs all tests
• BRule 2 — No duplication
• CRule 3 — Expressive code
• DRule 4 — Minimal classes/methods

Multiple choice

Why does Martin advocate using standard design pattern names (Visitor, Command, etc.)?

• APattern-named classes execute faster at runtime
• BThe SOLID principles formally require their use
• CThey reduce the total class count in a codebase
• DStandard names communicate intent and structure to readers more efficiently than ad-hoc code

Concurrency

Concurrency is a decoupling strategy that separates what gets done from when it gets done, improving throughput and structure. But concurrent code is hard to write correctly, hard to test, and failures are often non-reproducible — so it requires defensive design and disciplined separation of concerns.

Concurrency as Decoupling

Concurrency decouples what from when, transforming applications from sequential mini-programs into many collaborating computers. This improves throughput and structure but adds complexity.

Concurrency Myths

Concurrency does not always improve performance, sometimes degrades it, and is never free in design cost. Correct concurrent design is fundamentally different from single-threaded design.

SRP for Threads

Concurrency-related code should be separated from other code. Threading is complex enough on its own — mixing it with business logic produces unmaintainable systems.

Limit Shared Data Scope

The more places shared data is touched, the more likely synchronization is forgotten. Use encapsulation and keep critical sections small and few.

Use Copies of Data

Avoid sharing where possible by giving each thread its own copy, then merging results in one thread. Copy overhead is usually cheaper than synchronization bugs.

Threads as Independent Worlds

Each thread should behave as if it lives in its own world, sharing nothing. This is the model behind servlets and most web request handlers.

Know the Classic Problems

Understand Producer-Consumer, Readers-Writers, and Dining Philosophers, plus the basic models — bound resources, mutual exclusion, starvation, deadlock, livelock. Most concurrency bugs are variations.

Race Condition

Threads competing for a shared resource where execution order changes results.

Deadlock

Threads each waiting on resources held by the others — all halt.

Livelock

Threads stay active but make no progress because they keep yielding.

Starvation

A thread perpetually denied access to a resource.

Critical Section

Code accessing shared resources that must run on one thread at a time.

Atomic Operation

Completes in a single indivisible step relative to other threads.

Client-Based Locking

Client locks the shared object before use; fragile vs. server-based locking.

True / False

Adding concurrency to a system reliably improves its performance.

• TrueTrue
• FalseFalse

Multiple choice

What does "SRP for threads" recommend?

• ASpin up one thread per responsibility in the application
• BEach thread should carry exactly one instance variable
• CKeep concurrency-related code separated from other code; don't mix threading with business logic
• DThreads should never share any data, only message-pass

Spot the issue

What concurrency principle is violated?

class Tally {
  constructor() { this.count = 0; }
  add(n) { this.count += n; }
  get() { return this.count; }
}
// shared across many threads, freely read/written everywhere

• AUse copies of data
• BLimit shared data scope — the more places shared state is touched, the more likely synchronization is forgotten
• CThreads should be daemons
• DTally should be immutable

Multiple choice

What is a deadlock?

• AA thread perpetually denied a resource it needs (starvation)
• BA thread that keeps yielding without making progress (livelock)
• CA thread that holds a lock forever after its work has completed
• DThreads each waiting on resources held by the others — none can proceed

Successive Refinement

Using a command-line argument parser as a case study, Martin shows that clean code rarely arrives clean — it is the product of successive refinement through many small, safe changes. Even well-intentioned code rots when functionality is added without continuous cleanup.

Programming Is a Craft

To write clean code, you must first write dirty code and then clean it. First drafts are ugly; the discipline is in refining them, not shipping them.

The "Just Make It Work" Trap

Code starts clean with narrow scope, then degrades rapidly when scope expands without restructuring. Martin admits he fell into this trap himself — once it "worked," he kept piling on.

Continuous Improvement Over Big Rewrites

The fix is not to scrap and rewrite, but to refactor in tiny, test-protected steps. The Boy Scout Rule scales; the heroic rewrite does not.

Tests Enable Fearless Refactoring

A comprehensive test suite is what makes incremental refinement possible. Without tests, every change risks breakage and developers freeze.

Refactor in Tiny Steps

Each step should be small enough to keep tests passing. Large refactorings are made of many tiny reversible moves — never one sweeping change.

Separate Concerns During Refinement

A common refinement is to extract distinct responsibilities — parsing schema vs. parsing arguments vs. handling errors — into separate classes following SRP.

Stop Degradation the Moment You See It

Don't wait until "later." Letting bad code accumulate leads to unmaintainable systems, and the cost compounds exponentially over time.

Successive Refinement

An iterative discipline of repeated small improvements rather than rewrites.

Refactoring

Changing code structure without changing behavior, verified by tests.

Boy Scout Rule

Leave the campsite cleaner than you found it.

Software Rot

Gradual quality decline as features pile up without cleanup.

Test-Driven Refinement

A fast, comprehensive test suite as the safety net for restructuring.

Schema (Args)

A small DSL describing expected command-line arguments and types.

SRP

Single Responsibility Principle — the primary lens for decomposing the Args module.

Multiple choice

Martin admits he fell into the "just make it work" trap with the Args parser. What was the lesson?

• AThe first draft should be the final draft once it passes its tests
• BHand-written parsers should be avoided in favor of generators
• COnce code "works," developers tend to pile on more without restructuring — and it degrades fast
• DCommand-line tools don't warrant clean-code discipline

True / False

When a module gets messy, the right move is usually to scrap it and rewrite from scratch.

• TrueTrue
• FalseFalse

Multiple choice

What makes "tiny step" refactoring possible?

• AA senior architect's review on every change
• BPair programming on every refactor
• CStatic type checking catching regressions at compile time
• DA comprehensive test suite that runs quickly and catches regressions

Spot the issue

A teammate says: "The parser works for now. We'll clean it up after the release — it's not that bad yet." What's Martin's response?

• AReasonable — ship first, polish later
• BStop degradation the moment you see it; bad code compounds and "later" rarely arrives
• CAcceptable if a JIRA ticket is filed
• DFine as long as tests pass

JUnit Internals

A walkthrough of refactoring JUnit's ComparisonCompactor class shows that even code by master practitioners benefits from continued cleanup. The chapter teaches that good code is rewritten code, and applies concrete techniques — better naming, eliminating negatives, removing duplication — to real production code.

No Code Is Above Refactoring

Even JUnit, written by Kent Beck and Erich Gamma, contains code that can be improved. Quality is always a moving target.

Negatives Are Harder Than Positives

Conditions like `if (!shouldNotCompact())` impose cognitive load. Refactor double negatives into clear positive forms — `if (canBeCompacted())`.

Make Temporal Couplings Explicit

When functions must be called in a particular order, that ordering should be obvious — pass results between functions rather than relying on hidden instance state.

Standard Member Variable Placement

Member variables belong at the top of the class. Following standard conventions makes code more scannable and reduces surprise.

Rename for Clarity Continuously

Names like `f` and `s` lose meaning quickly. Replace cryptic identifiers with intention-revealing names like `expected` and `actual`, even mid-refactor.

Eliminate Hidden Duplication

Look for repeated patterns of logic — even subtle ones — and extract into well-named helpers. Duplication is the root of much evil.

Refactoring Is Iterative and Imperfect

Each pass reveals new improvements. There's no finish line — only "better than before" — and you must know when to stop for now.

ComparisonCompactor

The JUnit class refactored in the chapter; produces concise comparison failure messages.

Intention-Revealing Names

Names that clearly state purpose without comments.

Temporal Coupling

A dependency where operations must occur in a specific order, often hidden.

Negation Inversion

Refactoring `!isNotX()` into `isX()`.

Encapsulating Conditionals

Wrapping a boolean expression in a well-named method.

Method Extraction

Pulling a fragment into its own method for naming and reuse.

Inline Variable

Removing a redundant variable whose name adds no information.

Spot the issue

What does Martin flag here?

if (!shouldNotCompact(expected, actual)) {
  return original;
}

• AThe function name is too long
• BDouble negatives like `!shouldNotCompact` impose cognitive load — invert into a positive form
• CThe condition should be a switch
• D`return` should be `throw`

Multiple choice

What's the lesson of refactoring JUnit's ComparisonCompactor?

• AEven code by master practitioners (Beck, Gamma) can be improved
• BJUnit is poorly written
• CRefactoring is only for junior code
• DLibrary code is exempt from clean-code rules

Spot the issue

What's the smell?

class Compactor {
  fingerprint() { /* uses this.f */ }
  compact() { /* must be called AFTER fingerprint */ }
}

• AMember variables are private when they should be public
• BThe class name is too generic for its purpose
• CHidden temporal coupling — `compact` silently depends on `fingerprint` running first
• DThe methods should be static utilities

True / False

Once you finish a refactor pass, the code is "done" and shouldn't be touched again.

• TrueTrue
• FalseFalse

Refactoring SerialDate

A code review and refactoring of SerialDate from JCommon shows that even thoughtful, professional code suffers from outdated abbreviations, weak tests, and structural cruft. The chapter exemplifies professional courtesy — critique aimed at improving the craft — and uses Chapter 17's smells as the lens.

Professional Critique Improves the Craft

Refactoring others' code is an act of respect, not insult. Authors should welcome — and reviewers should offer — direct feedback aimed at the code, not the coder.

Aggressive Test Coverage First

Existing tests rarely cover boundary conditions adequately. Step one in refactoring is strengthening the test suite so refactoring is safe.

Eliminate Useless Comments

Out-of-date, redundant, or noise comments should be deleted. Comments that merely restate code add maintenance burden without value.

Names Reveal Purpose, Not Implementation

`SerialDate` names an implementation detail — Serial = serializable. Better names reflect what the class does or is — e.g., `Day`.

Delete Dead Code and Unused Abstractions

Methods, fields, and even whole abstractions that are never used should be deleted. YAGNI — they only obscure the code that matters.

Magic Numbers Become Named Constants

Bare numeric and string literals — especially repeated ones — belong in named constants with explanatory names that document intent.

Separate Static and Instance Concerns

When a class mixes factory-like static methods with instance behavior, clarify the design by splitting responsibilities or formalizing the factory.

SerialDate

The abstract date class from JCommon used as the refactoring subject.

Boundary Conditions

Edge inputs (leap years, month-end) where bugs hide and tests are weakest.

Magic Number

A bare literal with no name or explanation.

Dead Code

Methods, branches, or variables never executed in production.

YAGNI

"You Aren't Gonna Need It" — don't build until actually needed.

Code Review as Refactoring

Reviewing equals rewriting in your head, then proposing changes.

Switch Statement Smell

Long if-else chains often better replaced by polymorphism or lookup.

Multiple choice

Why does Martin argue `SerialDate` is a poor class name?

• AIt names an implementation detail (Serial = serializable) instead of what the class represents
• BIt is too long to read comfortably
• CIt uses CamelCase instead of snake_case
• DIt conflicts with a reserved Java keyword

Spot the issue

What should change?

if (day === 1) return 'Sunday';
if (day === 7) return 'Saturday';
// scattered across many files:
if (someDate.day === 1) { ... }

• AInline the values for performance
• BThe magic numbers `1` and `7` should become named constants like `SUNDAY` and `SATURDAY`
• CUse BigInt
• DConvert to a switch statement

True / False

Refactoring someone else's code is rude and should be avoided.

• TrueTrue
• FalseFalse

Multiple choice

Before refactoring SerialDate, Martin's *first* move was to:

• ARename every identifier to a consistent camelCase style
• BPort the module to a more modern language
• CStrengthen the test suite, especially around boundary conditions
• DExtract a base class to host common behavior

Smells and Heuristics

A comprehensive catalog of code smells and heuristics organized by category — Comments, Environment, Functions, General, Java, Names, Tests. It serves as both reference and rubric: a working programmer's checklist for spotting and naming problems in their own code.

Comment Smells

Comments that restate code, are out of date, or are commented-out code left "just in case" should be deleted. Source control remembers; comments lie.

Function Smells

Functions should take few arguments (zero is best), avoid boolean flag parameters (which signal the function does two things), and dead functions should be removed.

Duplication Is the Root of Evil

Every form of duplication — literal, structural, conceptual — should be aggressively extracted into a single source of truth. DRY is the primary lever.

One Level of Abstraction per Function

Mixing high-level and low-level detail in one function confuses readers. Don't organize code arbitrarily — every structural decision needs a reason.

Name Smells

Names should reveal intent, distinguish concepts in the reader's domain, and be greppable. Avoid encodings — Hungarian notation, member prefixes — and inconsistent terms.

Test Smells

Tests must cover everything that could possibly break, especially boundary conditions, and must be fast. Slow tests don't get run; trivial tests still document intent.

Environment Smells

A project must be buildable with a single command and testable with a single command. Friction here is the silent killer of quality.

Code Smell

A surface indication that usually corresponds to a deeper problem.

Heuristic

A rule of thumb — works most of the time but requires judgment.

DRY

Don't Repeat Yourself — every piece of knowledge has one unambiguous representation.

Feature Envy

A method using more of another class than its own.

Dead Code

Code never executed; should be removed, not preserved "just in case."

Inappropriate Static

A static method that should be polymorphic — a skipped OO decision.

Hidden Temporal Coupling

Order-dependent calls where the order isn't enforced by the API.

Artificial Coupling

Tying together things that don't depend on each other.

Spot the issue

What's the most prominent smell?

function applyDiscount(order, isVip) {
  if (isVip) {
    order.total *= 0.8;
  } else {
    order.total *= 0.95;
  }
}

• AVariable `order` is mutated
• BBoolean flag parameter — `isVip` proves the function does two different things
• CMagic numbers `0.8` and `0.95`
• DFunction returns nothing

Multiple choice

Why does Martin treat duplication as "the root of evil"?

• AIt bloats compiled binary size
• BIt confuses static analyzers and IDEs
• CEvery form of duplication — literal, structural, conceptual — fragments knowledge and forces multi-site updates
• DIt is incompatible with dependency injection containers

True / False

Slow tests are acceptable as long as they're thorough.

• TrueTrue
• FalseFalse

Multiple choice

What does Martin's "environment smell" boil down to?

• AThe choice between cloud CI and local CI runners
• BThe choice between static and dynamic type systems
• CThe physical office environment (noise, lighting, layout)
• DA project must build with a single command and test with a single command — friction here silently kills quality