Design, test, refactor, review, estimate and run software the way professional teams do.

Software Engineering Practices

## Why it matters

Code is read far more often than it is written. A feature you ship today will be changed next month by a teammate, or by you after you have forgotten the details. Design principles are rules of thumb that make that change cheaper. They are not laws: applied blindly they produce code that is harder to follow, not easier. This lesson covers the two you will use every day, **single responsibility** and **DRY**, and the judgement that goes with them.

## Single responsibility

The single responsibility principle (the "S" in SOLID) says a unit of code should have **one reason to change**. "Reason to change" means a person or a requirement: the finance team changes tax rules, the design team changes how a receipt looks, the API team changes the input format. If one function has to change for all three, those concerns are tangled together.

Here is a function that does too much:

```javascript
function receipt(csv) {
  let total = 0;
  const lines = csv.trim().split("\n");
  for (const line of lines) {
    const [name, qty, price] = line.split(",");
    total += Number(qty) * Number(price);
  }
  const tax = total * 0.08;
  return "Total: $" + (total + tax).toFixed(2);
}
```

It parses text, does arithmetic, applies a tax rule and formats money. To test the tax rule you have to build a CSV string and then pick a number out of a sentence. Split it by responsibility:

```javascript
function parseLine(line) {
  const [name, qty, price] = line.split(",").map((s) => s.trim());
  return { name, qty: Number(qty), price: Number(price) };
}

function lineTotal(item) {
  return item.qty * item.price;
}

function formatMoney(amount) {
  return "$" + amount.toFixed(2);
}

function receipt(csv, taxRate) {
  const items = csv.trim().split("\n").map(parseLine);
  const subtotal = items.reduce((sum, item) => sum + lineTotal(item), 0);
  return "Total: " + formatMoney(subtotal * (1 + taxRate));
}
```

Each small function can be tested on its own, and `receipt` now reads like a summary of the steps. Notice the tax rate became a parameter: the rule no longer hides inside the code.

## DRY: don't repeat yourself

DRY is often summarised as "never copy code", but the original idea (from *The Pragmatic Programmer*) is narrower: **every piece of knowledge should have one authoritative place**. If the minimum password length is 8, that number should live in one constant, not in the signup form, the reset form and the API validator separately. When the rule changes to 12, you change one line.

```javascript
const MIN_PASSWORD_LENGTH = 8;

function isValidPassword(pw) {
  return typeof pw === "string" && pw.length >= MIN_PASSWORD_LENGTH;
}
```

## Use them judiciously

Both principles can be overdone.

- **Accidental duplication is not real duplication.** Two functions may look the same today but represent different rules. A shipping fee and a service fee might both be "5% of the subtotal" this year. If you merge them into one `fivePercent()` helper, the day one of them changes you will add a flag, then another, and the shared helper becomes harder to read than the two copies were.
- **The rule of three.** Many teams wait until the third copy before extracting a helper. By then the shared shape is clear.
- **Tiny functions everywhere.** Splitting a clear ten-line function into six two-line functions makes readers jump around. Split when a piece has its own name, its own reason to change, or its own tests.
- **Wrong abstraction costs more than duplication.** If a shared helper grows a parameter for every caller, inline it back into its callers and start again.

A useful question before extracting anything: *if this rule changes, should every caller change with it?* If yes, share it. If no, keep the copies.

## Other principles you will hear about

SOLID also includes open/closed, Liskov substitution, interface segregation and dependency inversion. In everyday JavaScript the most practical of these is **dependency inversion**: pass things like the clock, the database or the mailer into a function instead of reaching for globals. You will use that in the testing lesson. **KISS** (keep it simple) and **YAGNI** (you aren't gonna need it) are reminders not to build flexibility you have no use for yet.

## Common mistakes

- Treating "one responsibility" as "one line" and fragmenting code.
- Merging code that only looks alike, then adding boolean flags to tell callers apart.
- Leaving magic numbers (`0.08`, `8`) scattered through the code instead of naming them once.
- Mixing input parsing, business rules and output formatting in one function, so nothing can be tested alone.

## Recap

- Single responsibility: one reason to change per unit. Separate parsing, rules and formatting.
- DRY is about knowledge, not characters. Give each rule one home.
- Duplication is cheaper than the wrong abstraction. Share code when the callers should change together.

## Try it

Open the **Do** tab and split a tangled receipt function into small, testable pieces.


Apply single responsibility and DRY with judgement, so code is easy to test and change.

Design principles

Single Responsibility Principle Explained - SOLID Design Principles

Programming Terms: DRY (Don't Repeat Yourself)

## Why it matters

A **design pattern** is a named, reusable shape for solving a problem that keeps coming up. The value of the name is communication: when a reviewer writes "this switch statement wants to be a strategy", everyone on the team knows what change is being suggested. The classic catalogue (the 1994 "Gang of Four" book) lists 23 patterns written for class-based languages. In JavaScript many of them shrink to a few lines because functions are values. This lesson covers two you will meet constantly in real code: **strategy** and **adapter**.

## Strategy: swap the algorithm, keep the caller

Use a strategy when you have several interchangeable ways to do one job and the choice is made at run time. A typical smell is a growing `switch`:

```javascript
function shippingCost(order, method) {
  switch (method) {
    case "standard": return 5;
    case "express": return 5 + order.weightKg * 2;
    case "pickup": return 0;
    default: throw new Error("Unknown method");
  }
}
```

Every new shipping option edits this function, and every rule lives in one place that everybody touches. With a strategy, each rule becomes its own function and the caller looks it up:

```javascript
const shippingStrategies = {
  standard: () => 5,
  express: (order) => 5 + order.weightKg * 2,
  pickup: () => 0,
};

function shippingCost(order, method) {
  const strategy = shippingStrategies[method];
  if (!strategy) throw new Error("Unknown shipping method: " + method);
  return strategy(order);
}
```

Adding "overnight" is now a new entry, not an edit to existing logic (this is the open/closed principle in practice). Each strategy is a pure function you can test alone. You have used this pattern already if you have passed a compare function to `array.sort((a, b) => a - b)`: the sort algorithm stays the same while the comparison strategy changes.

One caution: an object lookup like `shippingStrategies[method]` will also find inherited keys such as `"toString"`. When the key comes from user input, check with `Object.hasOwn(shippingStrategies, method)`, or build the map with `Object.create(null)` or a `Map`.

## Adapter: make one interface look like another

Use an adapter when you have code that expects one shape and a dependency that provides a different one. Instead of changing every caller, or forking the library, you write a thin translation layer.

Suppose your app works with users shaped like `{ id, name, email }`, and you integrate an old system that returns:

```javascript
const legacy = { user_id: "42", first_name: "Ada", last_name: "Lovelace", mail: "ADA@EXAMPLE.COM" };
```

Write one function that converts at the boundary:

```javascript
function adaptLegacyUser(raw) {
  return {
    id: Number(raw.user_id),
    name: (raw.first_name + " " + raw.last_name).trim(),
    email: raw.mail.toLowerCase(),
  };
}
```

The rest of your code never learns that the legacy format exists. If the vendor changes field names, you fix one function. Adapters are also how you wrap third-party services, for example a payment provider whose method is `createCharge(cents)` behind your own `pay(amountDollars)` interface. That gives you a natural seam for tests: in a test you swap in a fake object with the same interface.

## How to choose

| Problem | Pattern |
|---|---|
| Several interchangeable rules, chosen at run time | Strategy |
| An existing interface does not match what your code expects | Adapter |
| You need to add behaviour around a function (logging, caching) without changing it | Decorator (a wrapper function) |
| Many parts of the app need to react when something happens | Observer (events, `addEventListener`) |

## Common mistakes

- **Patterns for their own sake.** Two `if` branches do not need a strategy map. Reach for the pattern when the third or fourth case arrives, or when the rules need separate tests.
- **Leaky adapters.** If callers still check `raw.first_name` anywhere, the adapter is not doing its job. Convert once, at the edge.
- **Adapters that add business logic.** An adapter translates. Discount rules belong in your domain code, not in the layer that renames fields.
- **Silently ignoring unknown strategies.** Throw a clear error (or return a well-defined default) when the name is not found.

## Recap

- A pattern is a shared name for a proven shape; its biggest benefit is communication.
- Strategy: put interchangeable rules behind one function signature and pick one at run time.
- Adapter: translate an external shape into the shape your code expects, at the boundary.
- In JavaScript both are usually plain functions and objects, not class hierarchies.

## Try it

In the **Do** tab, replace a discount `switch` with a strategy map and write an adapter for a payment provider.


Use the strategy pattern to swap rules at run time and the adapter pattern to wrap an external interface.

Common design patterns

10 Design Patterns Explained in 10 Minutes

Strategy Pattern – Design Patterns (ep 1)

Write 3–4 functional requirements (for example: create a paste, view a paste by link, pastes expire after 30 days) and 2–3 non-functional ones (latency, availability, maximum paste size).

Estimate the load: assume 100,000 new pastes a day, 10 views per paste and an average of 5 KB per paste. Work out writes per second, reads per second and storage per year. Show your arithmetic.

Define the API: write the request and response for creating a paste and for viewing one, including the status code when a paste does not exist or has expired.

Design the data model: list the table(s) or collection(s), the fields, the primary key and how you will find expired pastes.

Draw the high-level design: client, load balancer, app servers, cache, database, and anything else you need. Label each arrow with what flows along it.

Name the first bottleneck at 10 times your estimated traffic and how you would fix it (cache, read replica, object storage for large pastes, or something else).

Write down what happens when one app server, the cache, or the primary database fails.

Compare your design with a friend's or with the URL shortener in the reading, and list one thing you would change.

## Why it matters

Writing a correct function is one skill. Deciding how the pieces of a service fit together, so that it keeps working when ten times more people use it, is another. **System design** is that second skill: choosing components (servers, databases, caches, queues), how they talk, and where the limits are. You will use it when you plan a new feature at work, read a design doc from a teammate, or answer a system design interview question. You do not need to be an expert in distributed systems to start. You need a repeatable process and a handful of building blocks.

## A repeatable process

1. **Clarify requirements.** Write down what the system must do (functional requirements) and how well (non-functional: latency, availability, data size). "Users can shorten a URL and be redirected" is functional. "Redirects should take under 100 ms and the service should survive one server failing" is non-functional.
2. **Estimate the load.** Rough numbers decide the design. 1,000 new links a day fits on one small server; 100 million a day does not.
3. **Define the API.** What requests come in and what goes out.
4. **Design the data model.** What you store and how you look it up.
5. **Draw the high-level design.** Boxes and arrows: client, load balancer, app servers, database, cache.
6. **Find the bottlenecks and fix the biggest one.** Then repeat.

## Worked example: a URL shortener

**Requirements.** Create a short link for a long URL; visiting the short link redirects to the long one. Links never expire. Reads (redirects) are far more common than writes.

**Estimate.** Say 1 million new links a day and 100 redirects per link over its life.

- Writes: 1,000,000 / 86,400 seconds is about **12 per second**.
- Reads: 100 times that, about **1,200 per second** on average; plan for peaks of maybe 5 times the average.
- Storage: about 500 bytes per link × 365 million links a year is roughly **180 GB a year**. That fits comfortably in one managed database for years.

The numbers say: reads dominate, storage is modest, and one database is fine at first.

**API.**

```http
POST /links        { "url": "https://example.com/very/long/path" }  -> 201 { "code": "aZ3kQ9" }
GET  /:code        -> 301 Location: https://example.com/very/long/path   (or 404)
```

**Data model.** One table, `links(code PRIMARY KEY, url, created_at)`. The primary key makes lookups by code fast. The code can be a random 6–8 character string from 62 symbols (a–z, A–Z, 0–9): 62^7 is about 3.5 trillion combinations, so collisions are rare; on insert, retry if the code already exists.

**High-level design.**

```text
client -> load balancer -> app servers (stateless, 2+) -> cache -> database
```

- **Stateless app servers** keep no user data in memory, so you can run two or more behind a **load balancer** and lose one without downtime. Adding servers is **horizontal scaling**; buying a bigger server is **vertical scaling**. Vertical is simpler until you hit the biggest machine or need redundancy.
- A **cache** (an in-memory key-value store such as Redis) holds popular `code -> url` pairs. Since a small share of links get most of the traffic, the cache absorbs most reads and the database sees a fraction.
- A **database replica** (a read-only copy) can serve reads if the cache is not enough, and takes over if the primary fails.

**Bottlenecks.** At 6,000 peak reads per second, the database would be the first thing to struggle without a cache. With a cache, the next questions are: what happens when the cache is empty after a restart (a "cold cache"), and how do you stop one client creating millions of links (rate limiting)?

## Building blocks to know

- **Load balancer:** spreads requests across servers and stops sending to unhealthy ones.
- **Cache:** fast, temporary copy of data; you must decide when entries expire or are invalidated.
- **Replication:** copies of the database for read capacity and failover.
- **Sharding (partitioning):** splitting data across several databases by a key, when one machine cannot hold or serve it all. It adds real complexity, so it comes late.
- **Queue:** lets one part of the system hand work to another without waiting (sending emails, generating thumbnails).
- **CDN:** serves static files from servers close to the user.

## Common mistakes

- Drawing boxes before writing requirements and numbers.
- Designing for a billion users when the estimate says ten thousand. Start simple; show how it would grow.
- Forgetting failure: what happens when a server, the cache or the database goes down?
- Keeping session state on one app server, which breaks load balancing.

## Recap

- Requirements, estimates, API, data model, diagram, bottlenecks: in that order.
- Back-of-the-envelope numbers decide whether you need a cache, replicas or sharding.
- Stateless servers behind a load balancer scale horizontally; caches protect the database.

## Try it

In the **Do** tab, design a small service on paper using the same six steps.


Sketch a scalable web service with requirements, estimates, an API, a data model and a diagram.

Intro to system design

20 System Design Concepts Explained in 10 Minutes

System Design BASICS: Horizontal vs. Vertical Scaling

Apply single responsibility and DRY with judgement, use the strategy and adapter patterns, and sketch a scalable web service.