Free through lesson 3

Intro to Design & Refactoring

From naming, splitting up functions, and early returns, through SOLID, dependency injection, ports and adapters, characterization tests, and ADRs. Across 30 lessons you'll get to the point where you can turn "working code" into "readable, easy-to-change code." Every lesson lines up a before and after in both Python and Java, and confirms with a test that the same input still returns the same answer.

Start from lesson 1 Unlock every course

Curriculum

The 30 lessons are split into 6 chapters. We recommend working through them in order starting from Chapter 1, but feel free to skim just the parts you're curious about. * The code was actually run against Python 3.14 with pytest 9, and Java 21. Lessons that only need the standard library let you run before and after right in the browser and compare them. Try the pytest and Java tests locally.

Chapter 1 — Start with Readability (lessons 1–5)

Fix the things that snag you the moment you read the code: names, function length, comments, and nesting depth. We finish by learning to spot magic numbers and duplication as "code smells," giving you a checklist of what to fix.

1

Naming (Expressing Intent Through Names)

What refactoring actually is, and how to let names carry your intent. Replace calc(d) and x[0] with total_amount and OrderLine, and confirm with a test that the total of 1300 hasn't changed.

Free
2

Function Length (Splitting into Stages)

Split make_receipt, which handles parsing, validation, calculation, and formatting at once, into one function per stage. Wherever you'd want a comment marking off a paragraph is where to split.

Free
3

Whether You Need a Comment (Keep the Why)

Remove comments that just restate code; let names carry meaning and keep only the "why." A comment belongs where reasoning can't be read from code — like why the member discount applies before tax.

Free
4

Early Returns (Guard Clauses)

Flatten a shipping-fee calculation buried four levels of nesting deep with guard clauses. Handle the exceptional cases first with return or raise, so what's left is just the normal path.

🔒 Basic
5

Code Smells (Magic Numbers and Duplication)

How to spot "code smells," the signs that tell you what to fix. Clean up unnamed numbers and identical male/female BMI checks into constants and a single function.

🔒 Basic

Chapter 2 — Organizing Functions and Data (lessons 6–10)

Rebuild the shape of your logic and data with function extraction, removing duplication, and parameter objects. We finish by separating side effects from queries and updates, arriving at functions that are easy to test.

6

Extracting a Function (Naming a Calculation)

Pull the average-score calculation a comment was explaining out into average_score, leaving the caller expressing just "what it wants." The five extraction steps, which your editor can often handle.

🔒 Basic
7

Removing Duplication (Make Only the Differences Arguments)

Merge shipping-fee and service-fee calculations that share a skeleton but differ only in base and extra charges. Telling real duplication worth merging from coincidental duplication you shouldn't.

🔒 Basic
8

Parameter Object (Combining Latitude and Longitude into a Point)

Rework distance_km, which takes four positional floats, into one taking two Point arguments instead. Grouping args that travel together prevents mixing up latitude and longitude at the type level.

🔒 Basic
9

Isolating Side Effects (Separating Calculation from Display)

Split report_total, which mixes the total calculation with print, into a side-effect-free calc_total and a display-only function. Keep the calculation pure and push side effects to a thin outer layer.

🔒 Basic
10

Separating Queries from Commands (Command-Query Separation)

Split get_balance_and_charge_fee, which deducts a fee every time it returns the balance, into a query (balance) and a command (charge_fee). The rule that returning a value should never change state.

🔒 Basic

Chapter 3 — Principles of Object-Oriented Design (lessons 11–16)

Confirm each of the five principles — single responsibility, open/closed, Liskov substitution, interface segregation, and dependency inversion — one lesson at a time, each with a before and after. We finish by layering all five onto a single piece of code and seeing how the principles reinforce each other.

11

The Single Responsibility Principle (SRP)

Split Report, which changes for three reasons — aggregation, CSV export, notification — into one class per responsibility. SOLID's first principle: find responsibilities by who cares, and when.

🔒 Basic
12

The Open/Closed Principle (OCP)

Replace area, which grows another elif every time a new shape appears, with classes that each have their own area(). A design where a new type means just adding a class, never touching existing code.

🔒 Basic
13

The Liskov Substitution Principle (LSP)

An example where inheriting "a square is a rectangle" means changing the width also changes the height. SOLID's third principle: inheritance follows behavioral contracts, not linguistic categories.

🔒 Basic
14

The Interface Segregation Principle (ISP)

Split a bloated interface that forces a print-only device to also implement scan and fax into Printer, Scanner, and Fax. SOLID's fourth principle: split interfaces by what each caller actually needs.

🔒 Basic
15

The Dependency Inversion Principle (DIP)

Invert order processing, which directly constructs a MySQL storage class internally, by introducing an abstract OrderRepository. Swap in a DB-free in-memory version for tests.

🔒 Basic
16

Combining SOLID

Chapter 3 capstone: split notify — which mixes destination-specific ifs, message building, and sending — into parts using SOLID. Add a destination with a class; test with a fake Channel.

🔒 Basic

Chapter 4 — Cutting Dependencies (lessons 17–22)

Use dependency injection, ports and adapters, and layers to separate your core logic from the database, the clock, and the network. We finish with an exercise where you combine all of it to build a mini app yourself.

17

Dependency Injection (Passing In the Clock from Outside)

Rework a greeting function that calls datetime.now() internally so it takes a Clock from outside instead. Pass a fixed clock in tests to confirm the exact 6 p.m. boundary without waiting for it.

🔒 Basic
18

Ports and Adapters (Protecting the Core Rules from the Outside)

Split buy, which mixes a global dictionary and print directly into the business rule for deducting inventory, into a core, a port, and an adapter. Unit-test the core using only a fake adapter.

🔒 Basic
19

How to Split Layers (Entity, Use Case, Gateway)

Split register — which handles validation, business rules, and persistence at once — into entity, use case, and gateway layers. Dependencies point inward; add layers only when needed.

🔒 Basic
20

Testable Design (Creating a Seam)

Rework a lottery draw that calls random() internally so a number-returning function can be injected instead. Keep real randomness as default; test the boundaries at 5/6 and 30/31.

🔒 Basic
21

Avoiding Global State

Enclose a global counter, whose value depends on test order, inside an IdGenerator instance. Making state reachable only by whoever holds it, so you no longer need a cleanup reset().

🔒 Basic
22

[Project] A Mini App with Dependencies Cut

Rebuild a TODO app — which holds storage, ID generation, and listing in globals — by splitting it into entity, use case, and gateway. A capstone layering lessons 17-21's principles onto one app.

🔒 Basic

Chapter 5 — Letting Tests Protect You (lessons 23–27)

Learn to capture how untested code behaves right now, find seams to work through, and safely refactor in small steps. We finish with an exercise where you rebuild a legacy function while tests keep you safe.

23

Characterization Tests (Capturing the Current Answer)

Capture 84 cases of a legacy grading function's current output as test expectations. Keep quirky rules, like a perfect-attendance bonus, intact at first; clean up only the structure.

🔒 Basic
24

A Legacy Seam (Taking the Sender as an Argument)

A function that emails overdue borrowers directly — and really sends mail if tested — gets a seam taking the sender as an argument. Confirm who gets notified without sending a single email.

🔒 Basic
25

Changing in Small, Safe Steps (Confirm Green After Every Move)

Refactor a fare calculation involving distance, age, and holidays in four small moves: naming, two function extractions, and a guard clause. Run tests after every single step.

🔒 Basic
26

Explaining Variables and Queries (Naming a Condition)

Rework can_checkout, a tangle of and/or that recomputes the total twice, into something readable with explaining variables and one query. The final return reads almost like plain English.

🔒 Basic
27

[Project] Refactor While Tests Keep You Safe

Untangle a price calc where coupons, points, shipping, and tax all reuse variable t, splitting it into stage functions with a characterization test as a safety net. A capstone spanning lessons 23-26.

🔒 Basic

Chapter 6 — Keeping It Up as a Team (lessons 28–30)

Turn good design from one person's effort into a team habit with a code review lens, making technical debt visible, and recording design decisions (ADRs). We close out all 30 lessons by linking an ADR back to the code it describes.

28

A Code Review Lens (Four Common Comments)

Address the four most common review comments one at a time: naming, magic numbers, deep nesting, and repeated calculations. Also covers the review mindset of critiquing the code, not the person.

🔒 Basic
29

Technical Debt (Paying It Down Safely, Side by Side)

Place an old if-based tax-rate implementation side by side with a new table-driven one, switching between them with a flag as you migrate. The strangler pattern: don't rip out working debt at once.

🔒 Basic
30

Recording Design Decisions (ADRs)

Record the "why" behind swapping an if-branch for the Strategy pattern in one doc: context, decision, consequences. Keep an ADR beside the code, and wrap up the three threads spanning all 30 lessons.

🔒 Basic

Once you finish all 30 lessons, move on to the Intro to Systems Development course, which puts design decisions into your development process, or the Intro to Agile Scrum course, which brings review and retrospectives into your team's rhythm. If you want to go deeper on writing tests, there's also the Intro to Testing Techniques course. All courses unlock with a membership.