Software Engineering Flashcards

Coupling

A relationship between two pieces of code where changes to one require changes to the other, making both harder to understand.

Connascence

A concept in software design describing the degree to which parts of a program must change together; strong connascence indicates a poor design.

Grepable

Code that is easily searchable and can be quickly located or referenced in a codebase.

Self-documenting code

Code that is clear and understandable without needing external documentation due to its naming conventions and structure.

Promise (in JavaScript)

An object representing the eventual completion (or failure) of an asynchronous operation and its resulting value.

Asynchronous

A programming concept where operations can occur independently of the main program flow, allowing for non-blocking execution.

Regression test

A test that ensures that previously developed and tested software still performs after a change is made.

Linter

A static code analysis tool used to flag programming errors, bugs, stylistic errors, and suspicious constructs.

Test-driven development (TDD)

A software development approach where tests are written before code, guiding the design and implementation.

Hermetic tests

Tests that are completely isolated from the environment and ensure that their behavior does not depend on external factors.

Debugging

The process of identifying and resolving defects or issues within a software application.

Delta debugging

An automated debugging approach that helps isolate the changes causing a bug by systematically dividing the input set.

Observer effect

A phenomenon where the act of observing or measuring a system changes that system in some way.

Fuzzing

An automated testing technique that involves providing random or semi-random inputs to software to discover vulnerabilities.

Continuous integration (CI)

A software development practice where developers frequently integrate code into a shared repository, followed by automated builds and tests.

Branch coverage

A test suite quality metric that ensures all branches (true and false outcomes) of control structures in code are exercised.

Code review

The process where developers review each other's code to identify issues and improve quality before merging changes.

Specification

A document that outlines how a system should behave without detailing how the implementation will achieve it.

Build system

A tool that automates the processes of compiling source code, running tests, and creating deployable software artifacts.

Modularity

A design principle where a system is composed of separate, independent, and interchangeable components.

Abstraction

The process of hiding complex implementation details and showing only essential features of an object.

Information Hiding

The principle of restricting access to internal components of a class or module to reduce coupling.

Code Comments

Explanations embedded within the source code to provide clarity and context for developers.

Call Stack

A data structure that stores information about the active subroutines of a computer program, indicating the point to which the program should return.

Unit test

A software testing method where individual units or components of software are tested in isolation.

Integration test

A type of software testing where individual software modules are combined and tested as a group.

End-to-End Test

A testing methodology to test an application flow from start to finish, simulating real user scenarios.

Test Stub

A dummy program module or object that simulates the behavior of an actual component that the module being tested depends on.

Git

A widely used distributed version control system for tracking changes in source code during software development.

Version Control System (VCS)

A system that records changes to a file or set of files over time so that you can recall specific versions later.

Branching (Version Control)

The practice of creating an independent line of development to work on new features or fixes without affecting the main codebase.

Agile Development

An iterative and incremental approach to software development that focuses on collaboration, customer feedback, and adapting to change.

DevOps

A set of practices that combines software development (Dev) and IT operations (Ops) to shorten the development lifecycle and provide continuous delivery.

Deployment

The process of releasing software, including all the activities that make a software system available for use.

Pair Programming

An agile software development technique where two programmers work together at one workstation on the same code.

Merge Conflict

A situation that occurs when two or more developers make conflicting changes to the same section of a file, requiring manual resolution.

User Story

A short, simple description of a feature told from the perspective of the person who desires the new capability, typically a user or customer.

Functional Requirements

Statements that describe what the software system should do, outlining its specific functions and behaviors.

Non-Functional Requirements

Statements that describe how the software system should be, focusing on criteria like performance, security, and usability rather than specific functions.

Pull Request (PR)

A request made by a developer to merge changes from one branch into another, often used for code review and discussion.

Syntax

The set of rules that define the combinations of symbols that are considered to be correctly structured statements or expressions in a language.

Semantics (Programming)

The meaning of the statements and expressions in a programming language, determining what a program will do when executed.

Runtime

The period during which a program is executing on a computer system, as opposed to compile-time or design-time.

Compiler

A software program that translates source code written in one programming language (the source language) into machine code or another programming language (the target language).

Transpiler

A type of compiler that translates source code from one high-level programming language into another high-level programming language.

Static Code Analysis

The examination of computer software without executing the program, often performed by tools like linters to find potential errors or stylistic issues.

Code Smells

Any symptom in the source code of a program that possibly indicates a deeper problem, suggesting areas for refactoring.

Breakpoint

An intentional stopping or pausing place in a program, set by a debugger for examination of the program's state at that point.

Stack Trace

A report of the active stack frames at a certain point in time during the execution of a program, indicating the sequence of function calls.

Encapsulation

Bundling data and methods that operate on the data within a single unit, and restricting direct access to some of an object's components.

Interface (Programming)

A common boundary or set of rules that allows components or programs to interact with each other.

API (Application Programming Interface)

A set of definitions and protocols for building and integrating application software.

Design Patterns

Reusable solutions to common problems in software design.

Cohesion

The degree to which the elements inside a module belong together. High cohesion suggests good design.

DRY (Don't Repeat Yourself)

A principle where every piece of knowledge must have a single, unambiguous, authoritative representation within a system.

YAGNI (You Aren't Gonna Need It)

A principle stating that a developer should not add functionality until deemed necessary.

KISS (Keep It Simple, Stupid)

A design principle which states that most systems work best if they are kept simple rather than made complex.

SOLID Principles (SRP)

The Single Responsibility Principle, stating that a class should have only one reason to change.

SOLID Principles (OCP)

The Open/Closed Principle, stating that software entities should be open for extension, but closed for modification.

SOLID Principles (LSP)

The Liskov Substitution Principle, stating that objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.

SOLID Principles (ISP)

The Interface Segregation Principle, stating that clients should not be forced to depend on interfaces they do not use.

SOLID Principles (DIP)

The Dependency Inversion Principle, stating that high-level modules should not depend on low-level modules; both should depend on abstractions.

Technical Debt

The implied cost of additional rework caused by choosing an easy solution now instead of a better, more robust approach.

Refactoring

The process of restructuring existing computer code without changing its external behavior, to improve non-functional attributes.

Readability (Code)

The ease with which human readers can understand source code.

Naming Conventions (Code)

Rules for choosing the character sequence to be used for identifiers in source code.

Idiomatic Code

Code written in a style considered natural or standard for a particular programming language or ecosystem.

Maintainability (Code)

The ease with which a software system or component can be modified to correct faults, improve performance or other attributes, or adapt to a changed environment.

Dead Code

Code that is executed but whose results are never used in any other computation.

Documentation (Code)

Explanatory materials accompanying source code, often detailing its function, design, and how to use it.

Pseudocode

An informal high-level description of the operating principle of a computer program or algorithm.

Control Flow Analysis

A static analysis technique that determines the order in which statements are executed in a program.

Variable Scope

The region of a program where a defined variable can be recognized and used.

Function Signature

The definition of a function or method, specifying its name, parameters, and return type.

Return Type

The data type of the value that a function or method returns.

Exception Handling

A programming construct that allows dealing with the occurrence of exceptions (anomalous or exceptional conditions) during runtime.

Log File

A file that records events that occur in an operating system or other software runs, or messages between different users of a communication software.

Tracing (Code)

The process of observing the execution of a program, often by printing messages at key points or using a debugger.

Test Case

A set of conditions or variables under which a tester will determine whether a system under test satisfies requirements.

Test Suite

A collection of test cases that are intended to be used to test a software program to show that it has some specified set of behaviors.

Test Plan

A document that describes the scope, approach, resources, and schedule of intended test activities.

Acceptance Testing

A test conducted to determine if the requirements of a specification or contract are met by the delivery of the system.

User Acceptance Testing (UAT)

The final stage of testing, performed by end-users to verify that the system is fit for purpose and solves the business problem.

Black-box testing

A method of software testing that examines the functionality of an application without peering into its internal structures or workings.

White-box testing

A method of software testing that tests internal structures or workings of an application, as opposed to its functionality.

Performance Testing

Testing that is conducted to evaluate the speed, responsiveness, and stability of a computer, network, software program or device under a particular workload.

Stress Testing

Testing conducted to evaluate how a system performs under extreme loads, beyond its normal operating capacity.

Load Testing

Testing conducted to understand the behavior of the system under a specific expected load.

Security Testing

A type of software testing that uncovers vulnerabilities of the system and determines that the data and resources of the system are protected from intruders.

Mock Object

Simulated objects that mimic the behavior of real objects in controlled ways, often used in unit testing.

Test Double

A generic term for any object or component that takes the place of a real dependency in a test (e.g., mocks, stubs, fakes).

Test Coverage (General)

A measure used to describe the degree to which the source code of a program is executed when a particular test suite runs.

Statement Coverage

A white-box testing metric that reports if each executable statement in the source code has been executed at least once.

Decision Coverage

A white-box testing metric that reports if every possible outcome of each decision point (e.g., if-else conditions) has been executed.

Automated Testing

Testing methods that employ software tools to execute tests and report outcomes, reducing manual effort.

Manual Testing

Testing methods that involve a human performing tests manually, without the aid of automated tools.

Smoke Test

Preliminary tests to reveal simple failures severe enough to reject a prospective software release.

Sanity Test

A quick test to ascertain that after a change, the software still functions as expected.

Repository (Repo)

A central location where data is stored and managed, especially in version control systems, where it holds all files and their revision history.

Commit (VCS)

A snapshot of your changes to the project, saved to the repository history.