A reference from Weave

Find a term

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

Search results

237 terms

  • Continuous testing

    Continuous 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

  • Control-flow graph

    A graph that represents the possible paths of execution through a program.

    Code quality and technical debt

  • Coupling between objects

    A count of relationships a class or object has with other classes or objects.

    Code quality and technical debt

  • Cross-browser testing

    Cross-browser 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

  • Cyclomatic complexity density

    Cyclomatic complexity normalized by a measure of code size.

    Code quality and technical debt

  • Data debt

    Data 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

  • Data-flow analysis

    A static-analysis technique that tracks how values move through a program.

    Code quality and technical debt

  • Database migration

    Database migration 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

  • Dead code

    Code that cannot execute or whose result is never needed by the program.

    Code quality and technical debt

  • Decision table testing

    Decision table 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

  • Defect density

    The number of confirmed defects relative to a defined amount of software or change.

    Code quality and technical debt

  • Defect removal efficiency

    The proportion of defects found and removed before release compared with defects found before and after release.

    Code quality and technical debt

  • Deferred maintenance

    Deferred maintenance 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

  • Dependency age

    Dependency age 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

  • Dependency cycle

    A circular chain in which modules or packages depend on one another.

    Code quality and technical debt

  • Dependency fan-in

    The number of components that depend on a given component.

    Code quality and technical debt

  • Dependency fan-out

    The number of components that a given component directly depends on.

    Code quality and technical debt

  • Dependency graph

    A graph showing how software modules, packages, or services depend on one another.

    Code quality and technical debt

  • Dependency graph density

    A measure of how many dependency relationships exist relative to the possible relationships in a graph.

    Code quality and technical debt

  • Dependency inversion

    A design principle that places stable abstractions between high-level policy and volatile implementation details.

    Code quality and technical debt

  • Dependency management

    Dependency management 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

  • Dependency pinning

    Dependency pinning 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

  • Dependency update

    Dependency update 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

  • Dependency vulnerability

    Dependency vulnerability 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

  • Deployment debt

    Deployment 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

  • Deprecation

    Deprecation 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

  • Design debt

    Design 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

  • Disaster recovery testing

    Disaster 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

  • Distance from main sequence

    An architecture signal that combines abstractness and instability to highlight potentially problematic component positions.

    Code quality and technical debt

  • Divergent change

    A code smell in which one module changes for many unrelated reasons.

    Code quality and technical debt

  • Documentation debt

    Documentation 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

  • Efferent coupling

    The number of dependencies that a component sends outward to other components.

    Code quality and technical debt

  • Equivalence partitioning

    Equivalence partitioning 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

  • Error guessing

    Error guessing 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

  • Example-based testing

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

  • Extract method

    Extract method 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

  • Failover testing

    Failover 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

  • Feature envy

    A code smell in which one method appears more interested in another object’s data than in its own context.

    Code quality and technical debt

  • Gray-box testing

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

  • Inappropriate intimacy

    A code smell in which two modules know too much about each other’s internal details.

    Code quality and technical debt

  • Incremental refactoring

    Incremental 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

  • Infrastructure debt

    Infrastructure 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

  • Inline function

    Inline function 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

  • Instability metric

    A software architecture measure based on a component’s outgoing dependencies compared with its incoming dependencies.

    Code quality and technical debt

  • Integration debt

    Integration 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

  • Integration testing

    Integration testing checks whether two or more software components work together through their real or representative interfaces. It focuses on interactions such as application-to-database queries, service calls, message publishing, or framework configuration.

    Code quality and technical debt

  • Interface segregation

    A design principle that favors focused interfaces so clients depend only on what they use.

    Code quality and technical debt

  • Interface testing

    Interface 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

  • Internationalization testing

    Internationalization 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

  • Lack of cohesion

    A family of measures that estimates how weakly the responsibilities or data uses within a class are connected.

    Code quality and technical debt