Glossary

Abstraction

A named simplification that hides detail. Useful when it isolates a real change; harmful when it hides a decision you need to see. 05

Artifact

The built, immutable output of a pipeline — a container image, binary or bundle — promoted through environments rather than rebuilt. 09

Bisect

Binary search through commit history to find the change that introduced a bug: mark a good and a bad commit, let git narrow it. 07

Blue-green deployment

Two identical environments; traffic switches between them, so rolling back is switching back. 09

Branch

A movable label pointing at a commit. A place to be wrong safely. 03

Breakpoint

A debugger stop point where you can inspect real values instead of reasoning about them. 07

Canary release

Sending a small slice of traffic to a new version and promoting only if the measurements hold. 09

CI (continuous integration)

Every push is built and tested automatically, so breakage is found in minutes rather than at release. 09

CD (continuous delivery/deployment)

Every change that passes the pipeline is releasable, and (for deployment) released automatically. 09

Code smell

A surface signal that something may be wrong underneath — a long function, duplicated logic, a parameter that changes behavior. A hint, not a verdict.

Cohesion

How strongly the parts of a module belong together. High cohesion means one reason to change. 05

Commit

A labeled snapshot of the whole project, with a message explaining what and why. 03

Coupling

How much a change in one place forces changes elsewhere. Measured in blast radius, not in diagrams. 05

Coverage

The share of lines executed by tests. A proxy for "was it run", never for "was it verified". 06

Dependency injection

Passing collaborators in rather than constructing them inside, so behavior can be swapped and tested. 05

DRY

One authoritative place for each piece of knowledge — not one function for every similar-looking line. 05

E2E (end-to-end) test

A test that drives the whole system like a user. High confidence, slow, and prone to flakiness; keep it to critical journeys. 06

Feature flag

A runtime switch that exposes code independently of deployment — turning release into a toggle and rollback into a config change. 09

Flaky test

A test that passes and fails without code changes. Worse than no test: it teaches the team to ignore red. 06

Formatter

An automatic code layout tool. Ends style debates by making the choice once and mechanically. 02

Hotfix

A small, urgent change to production, ideally still through the pipeline and always followed by a regression test.

Incident

An unplanned event that harms or risks users. Its output is not blame but a changed system.

Integration test

A test of several components together, ideally with one real dependency, to catch wiring and contract bugs. 06

KISS

Among solutions that work, choose the simplest. Complexity is a permanent cost.

Linter

A static check for likely mistakes and consistency. Fails the build on errors so humans review intent instead of syntax. 02

Lockfile

A committed record of exact dependency versions, so every machine installs the same tree. 02

Merge

Joining two lines of history. Conflicts are a sign that two people changed the same place — a conversation, not a failure. 03

Migration

A versioned change to a data store. Do it in expand/contract steps so old and new code can run at once. 09

Mock

A test double standing in for a dependency. Useful at boundaries; dangerous when you end up testing the mock instead of the system. 06

Monorepo

Many projects in one repository, sharing tooling and history. Powerful with good boundaries, painful without them.

Observability

The ability to answer "what happened?" from logs, metrics and traces without adding new code. 09

Pair programming

Two people, one keyboard, continuous review. Expensive per hour, cheap per defect.

Pipeline

The automated sequence from commit to deployment, with a gate at each stage. 09

Postmortem

A blameless review after an incident: timeline, contributing causes, and the changes that follow.

Pull request (PR)

A proposed change plus its discussion — the unit of review, and ideally small. 08

Rebase

Replaying commits onto a new base. Clean history, new identities — never on shared branches. 03

Red-green-refactor

The TDD loop: a failing test, the minimum code to pass, then cleanup while green. 06

Refactor

A change to structure with no change in behavior, protected by tests. 05

Regression

Something that used to work and now doesn't. Every one deserves a test that would have caught it. 07

Reproduction

A deterministic way to trigger a bug. Without one, you have a hypothesis, not a fix. 07

Revert

A new commit that undoes an earlier one. The safe way to undo shared history. 03

Rollback

Returning to the previous known-good version. Should be fast, rehearsed, and boring. 09

Semantic versioning

major.minor.patch, where major signals a breaking change. A contract with your consumers. 09

Smoke test

A few checks of critical journeys right after deploy, to decide promote-versus-rollback in minutes. 09

SOLID

Five design principles; a lens for spotting fragility. Liskov (substitutability) is the one that prevents real bugs. 05

Spike

A time-boxed experiment to answer a question, then thrown away. Buy knowledge, not production code. 10

Staging

An environment that resembles production closely enough to trust the test results. 09

Stack trace

The call path at the moment of an error. Read it bottom-up: the last frame in your code is usually where to start. 07

Static analysis

Checks performed without running the code — types, linters, security scanners. Cheapest place to catch a bug. 02

Stash

Parking uncommitted changes in a drawer so you can switch context and come back. 03

Technical debt

A shortcut that trades future cost for present speed, ideally recorded so it can be repaid deliberately.

Test double

Any stand-in for a real dependency: stub, fake, spy or mock. 06

Test pyramid

Mostly unit tests, fewer integration tests, a handful of end-to-end ones — cheap and fast at the base. 06

Trunk-based development

Short-lived branches merged into main frequently, often behind flags. Small batches, fewer merge conflicts. 03

Unit test

A test of one behavior in isolation, in milliseconds, with no network or database. 06

YAGNI

You Aren't Gonna Need It: build for today's requirement, not a speculative future one.

No terms match that search.