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

  • Law of Demeter

    A guideline that limits how many unrelated object relationships a method navigates directly.

    Code quality and technical debt

  • Legacy modernization

    Legacy modernization 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

  • Legacy system

    Legacy system 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

  • Liskov substitution principle

    A design principle that requires a subtype to remain valid wherever its declared base type is expected.

    Code quality and technical debt

  • Load testing

    Load 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

  • Localization testing

    Localization 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

  • Maintainability risk

    The likelihood that future changes to a software area will be costly, error-prone, or difficult to validate.

    Code quality and technical debt

  • Maintainability testing

    Maintainability 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

  • Method length

    The amount of source text or statements contained in a method or function.

    Code quality and technical debt

  • Migration plan

    Migration plan 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

  • Model-based testing

    Model-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

  • Modular monolith

    Modular monolith 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

  • Module cohesion

    The degree to which the elements of a module support one focused purpose.

    Code quality and technical debt

  • Module stability

    The degree to which a module can change without forcing changes in its consumers.

    Code quality and technical debt

  • Module testing

    Module 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

  • Monolith decomposition

    Monolith decomposition 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

  • Mutation score

    Mutation score 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

  • Negative testing

    Negative 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

  • Nesting depth

    The maximum number of control-flow or structural levels nested inside one another.

    Code quality and technical debt

  • Observability debt

    Observability 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

  • Obsolete code

    Obsolete code 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

  • Open-closed principle

    A design principle that favors extending behavior through stable contracts rather than repeatedly modifying trusted code.

    Code quality and technical debt

  • Orphan abstraction

    An abstraction that has no clear owner, consumer, or responsibility in the current design.

    Code quality and technical debt

  • Orphaned code

    Orphaned code 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

  • Ownership debt

    Ownership 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

  • Pairwise testing

    Pairwise 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

  • Parallel inheritance hierarchies

    A code smell in which adding one subtype in one hierarchy requires adding a matching subtype in another.

    Code quality and technical debt

  • Parameter count

    The number of arguments accepted by a function, method, or constructor.

    Code quality and technical debt

  • Penetration testing

    Penetration 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

  • Performance debt

    Performance 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

  • Performance testing

    Performance 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

  • Portability debt

    Portability 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

  • Portability testing

    Portability 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

  • Primitive obsession

    A code smell in which domain concepts are represented by generic primitives instead of meaningful types.

    Code quality and technical debt

  • Process debt

    Process 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

  • Quality profile

    A named collection of analysis rules and settings applied to a codebase or language.

    Code quality and technical debt

  • Recovery testing

    Recovery 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

  • Refactoring backlog

    Refactoring backlog 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

  • Refactoring safety

    The confidence that a structural code change preserves externally observable behavior.

    Code quality and technical debt

  • Regression testing

    Regression testing repeats relevant tests after a software change to detect unintended effects on behavior that previously worked. It can use unit, integration, system, or end-to-end tests selected according to the change and the risks it may affect.

    Code quality and technical debt

  • Release debt

    Release 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

  • Reliability testing

    Reliability 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

  • Remove duplication

    Remove duplication 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

  • Rename refactoring

    Rename 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

  • Resilience debt

    Resilience 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

  • Resilience testing

    Resilience 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

  • Response for a class

    A measure of the number of methods potentially executed in response to a message received by a class.

    Code quality and technical debt

  • Rework rate

    Rework rate is the proportion of work that must be repeated or revised because the earlier result was incomplete, incorrect, or no longer suitable. Its calculation depends on the work unit and the evidence used to identify rework.

    Code quality and technical debt

  • Risk-based testing

    Risk-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

  • Rule suppression

    An explicit instruction that prevents a static-analysis rule from reporting a selected code location.

    Code quality and technical debt