A reference from Weave

Code quality and technical debt glossary

Understand maintainability, code structure, and the costs of decisions that make future changes harder. Learn what quality signals can and cannot establish.

All terms

237 terms

  • Abstract interpretation

    A static-analysis method that approximates program behavior with a simpler mathematical model.

    Code quality and technical debt

  • Abstract syntax tree

    A structural representation of source code that records its syntax as connected nodes.

    Code quality and technical debt

  • Abstractness metric

    A measure of how many types in a component are abstract rather than concrete.

    Code quality and technical debt

  • Acceptance test-driven development

    Acceptance test-driven development is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Acceptance testing

    Acceptance testing is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Accessibility debt

    Accessibility debt is a software maintenance concern describing a condition that can make future changes, verification, operation, or ownership harder. Its practical importance depends on supported behavior, rate of change, and the consequences of delay.

    Code quality and technical debt

  • Accessibility testing

    Accessibility testing is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Afferent coupling

    The number of incoming dependencies from other components into a component.

    Code quality and technical debt

  • Alpha testing

    Alpha testing is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Anti-corruption layer

    Anti-corruption layer is a software maintenance concern describing a condition that can make future changes, verification, operation, or ownership harder. Its practical importance depends on supported behavior, rate of change, and the consequences of delay.

    Code quality and technical debt

  • API churn

    The frequency or magnitude of changes to a public interface over a defined period.

    Code quality and technical debt

  • API surface area

    The amount of public functionality that a component exposes to external callers.

    Code quality and technical debt

  • API testing

    API testing is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • API versioning

    API versioning is a software maintenance concern describing a condition that can make future changes, verification, operation, or ownership harder. Its practical importance depends on supported behavior, rate of change, and the consequences of delay.

    Code quality and technical debt

  • Architectural boundary

    A defined separation between components that limits responsibilities, dependencies, or change impact.

    Code quality and technical debt

  • Architecture churn

    The rate at which major structural relationships or boundaries change over time.

    Code quality and technical debt

  • Architecture decision latency

    The elapsed time between an architecture question being raised and a decision becoming usable for implementation.

    Code quality and technical debt

  • Architecture decision record

    A short document that captures an important architecture decision, its context, and its consequences.

    Code quality and technical debt

  • Architecture fitness function

    An automated or repeatable check that tests whether an architecture continues to meet a chosen constraint.

    Code quality and technical debt

  • Architecture rework

    Engineering effort spent changing a structural design after implementation or adoption has begun.

    Code quality and technical debt

  • Automated refactoring

    Automated refactoring is a software maintenance concern describing a condition that can make future changes, verification, operation, or ownership harder. Its practical importance depends on supported behavior, rate of change, and the consequences of delay.

    Code quality and technical debt

  • Availability testing

    Availability testing is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Backward compatibility

    Backward compatibility is a software maintenance concern describing a condition that can make future changes, verification, operation, or ownership harder. Its practical importance depends on supported behavior, rate of change, and the consequences of delay.

    Code quality and technical debt

  • Behavior-driven development

    Behavior-driven development is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Behavior-preserving change

    Behavior-preserving change is a software maintenance concern describing a condition that can make future changes, verification, operation, or ownership harder. Its practical importance depends on supported behavior, rate of change, and the consequences of delay.

    Code quality and technical debt

  • Beta testing

    Beta testing is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Black-box testing

    Black-box testing is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Boolean parameter

    A function argument whose true or false value selects behavior or a mode.

    Code quality and technical debt

  • Boundary value analysis

    Boundary value analysis is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Branch by abstraction

    Branch by abstraction is a software maintenance concern describing a condition that can make future changes, verification, operation, or ownership harder. Its practical importance depends on supported behavior, rate of change, and the consequences of delay.

    Code quality and technical debt

  • Branch coverage

    Branch coverage is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Breaking change

    Breaking change is a software maintenance concern describing a condition that can make future changes, verification, operation, or ownership harder. Its practical importance depends on supported behavior, rate of change, and the consequences of delay.

    Code quality and technical debt

  • Breaking change rate

    The proportion of public interface changes that require consumers to modify or redeploy.

    Code quality and technical debt

  • Build debt

    Build debt is a software maintenance concern describing a condition that can make future changes, verification, operation, or ownership harder. Its practical importance depends on supported behavior, rate of change, and the consequences of delay.

    Code quality and technical debt

  • Bus factor

    The minimum number of people whose loss would put a project or critical area at serious operational risk.

    Code quality and technical debt

  • Cause-effect graphing

    Cause-effect graphing is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Change-proneness

    The tendency of a component to be modified repeatedly within a defined period.

    Code quality and technical debt

  • Characterization test

    Characterization test is a software maintenance concern describing a condition that can make future changes, verification, operation, or ownership harder. Its practical importance depends on supported behavior, rate of change, and the consequences of delay.

    Code quality and technical debt

  • Checklist-based testing

    Checklist-based testing is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Code age

    The elapsed time since a selected code element was last modified or introduced.

    Code quality and technical debt

  • Code archaeology

    Code archaeology is a software maintenance concern describing a condition that can make future changes, verification, operation, or ownership harder. Its practical importance depends on supported behavior, rate of change, and the consequences of delay.

    Code quality and technical debt

  • Code coverage

    Code coverage is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Code ownership concentration

    The degree to which changes to a code area are made or reviewed by a small set of contributors.

    Code quality and technical debt

  • Code quality gate

    An automated condition that must pass before a change can advance in a delivery workflow.

    Code quality and technical debt

  • Cognitive complexity trend

    The change over time in a codebase’s cognitive complexity measurements.

    Code quality and technical debt

  • Combinatorial testing

    Combinatorial testing is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Compatibility testing

    Compatibility testing is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Compliance debt

    Compliance debt is a software maintenance concern describing a condition that can make future changes, verification, operation, or ownership harder. Its practical importance depends on supported behavior, rate of change, and the consequences of delay.

    Code quality and technical debt

  • Component testing

    Component testing is a software testing or test-design practice used to gather evidence about a defined risk, behavior, boundary, or operating condition. It makes the question under test explicit, identifies the inputs and observations that matter, and gives a team a repeatable basis for deciding whether the result is acceptable.

    Code quality and technical debt

  • Configuration drift debt

    Configuration drift debt is a software maintenance concern describing a condition that can make future changes, verification, operation, or ownership harder. Its practical importance depends on supported behavior, rate of change, and the consequences of delay.

    Code quality and technical debt