| ... |
... |
@@ -3,13 +3,11 @@ |
| 3 |
3 |
| -------------------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | |
| 4 |
4 |
| **Term** | **Explanation** | |
| 5 |
5 |
| Abstraction | 1) The counterpart of 'concreteness', it refers to interfaces and abstract classes that define behavior (function signatures) but leave the internal implementation of those functions undefined. 2) A higher-level, generalized unit of code. Duplication across multiple functions can be resolved by creating an 'abstraction' - a separate function containing the shared code. This adheres to the DRY principle. | |
| 6 |
|
-| [[Acceptance Test|doc:Software Engineering.Agile.Extreme Programming.Acceptance Tests.WebHome]] | See link. | |
| 7 |
7 |
| [[Agile|doc:Software Engineering.Agile.WebHome]] | See link. | |
| 8 |
8 |
| Assertion | An assertion function, a crucial part of testing. If the input values don't satisfy a certain condition, the test containing the assertion fails. Example: `assertEquals(expectedResult, actualResult)`. | |
| 9 |
9 |
| Awareness | A class A is aware of class B if it contains a reference to class B in its source code. If no such reference exists, class A is unaware of class B. | |
| 10 |
10 |
| Behavior | Counterpart to implementation. It refers to the observable actions performed by a component. For example: A class may have the only observable method `sort(Collection: SomeCollection)`, which says what it does, but no implementation details like what concrete sorting algorithm is used. | |
| 11 |
11 |
| Best Practices | Widely accepted guidelines designed to enhance programming productivity and code quality. Adherence can prevent many potential issues. | |
| 12 |
|
-| Business Value | The worth of a feature in terms of its benefit to the business. | |
| 13 |
13 |
| Compile Time | The period when the code is compiled. Often used to distinguish from runtime. | |
| 14 |
14 |
| Concretion | The counterpart to 'abstraction', also known as 'implementation'. In OOP, refers to non-abstract classes that implement the methods of interfaces or abstract classes. A concretion provides the 'concrete' code defining the workings of these abstract functions. | |
| 15 |
15 |
| [[Constructor Injection|doc:Software Engineering.Architecture.Dependency Injection.Types of Dependency Injection.WebHome]] | A type of dependency injection in which dependencies are provided to an object through constructor arguments. | |
| ... |
... |
@@ -19,7 +19,6 @@ |
| 19 |
19 |
| [[Continuous Integration|doc:Software Engineering.Agile.Extreme Programming.Continuous Integration.WebHome]] (CI) | See link. | |
| 20 |
20 |
| Daemon | A program running in the background of a system, often without a GUI. | |
| 21 |
21 |
| Data Structure | A class primarily meant to hold data and provide basic operations to access and manipulate that data. May contain only public fields, or private fields with associated getter and setter methods. | |
| 22 |
|
-| [[Definition of Done|doc:Software Engineering.Agile.Extreme Programming.Acceptance Tests.WebHome]] | See link. | |
| 23 |
23 |
| Dependency | In context of classes, a dependency is an object required by another object to perform its functions. Often, dependencies are provided via dependency injection. | |
| 24 |
24 |
| Dependency Cycle | A situation where two or more classes depend on each other to be instantiated. This situation creates a circular dependency that makes object creation impossible. The dependency graph should be a directed acyclic graph rather than a cycle. | |
| 25 |
25 |
| [[Dependency Injection|doc:Software Engineering.Architecture.Dependency Injection.WebHome]] (DI) | A technique where an object's dependencies are provided from outside, rather than being created within the object itself. | |
| ... |
... |
@@ -43,7 +43,6 @@ |
| 43 |
43 |
| Magic | Code that performs complex tasks while abstracting away the complexity, presenting a simple interface to the user. | |
| 44 |
44 |
| Operating System (OS) | The foundational system software that manages and coordinates all computer resources. Examples are Windows, MacOS and Linux. | |
| 45 |
45 |
| Pain | An unpleasant experience caused by unnecessary efforts that could have been mitigated with better design of the original code. | |
| 46 |
|
-| [[Pair Programming|doc:Software Engineering.Agile.Extreme Programming.Pair Programming.WebHome]] / Pairing (up) | See link. | |
| 47 |
47 |
| Physical | Counterpart to logical. Refers to hardware. For example, physically deleting a file means removing it from the disk. | |
| 48 |
48 |
| Production Code | Code that comprises the functioning part of an application, as opposed to test code. | |
| 49 |
49 |
| Programmer | Someone who writes and tests code. The knowledge level of a beginner. | |
| ... |
... |
@@ -51,9 +51,7 @@ |
| 51 |
51 |
| Resources | Refers to the assets used in the project, including time, money, staff, and effort. | |
| 52 |
52 |
| Return of Investment (RoI) | Business value derived from implementing a story, minus the associated effort or cost. | |
| 53 |
53 |
| Rollback | The act of returning a system or data to a previous state, often using a snapshot. | |
| 54 |
|
-| Rotting Code | Code that is increasingly difficult to maintain due to multiple changes that accumulate technical debt by not following best practices. | |
| 55 |
55 |
| Runtime | The period when the code is being executed. Often used to distinguish from compile time. | |
| 56 |
|
-| Scope / Project Scope | The extent of features that must be implemented to deliver a project. | |
| 57 |
57 |
| Security | Measures implemented to protect systems from threats, unauthorized access, and vulnerabilities. This includes, but is not limited to, authentication, authorization, and encryption. | |
| 58 |
58 |
| Self-Containment | The ability of software to operate independently, without dependence on external services or factors. This characteristic ensures that its results are determined solely by its source code, which promotes stability and consistency. | |
| 59 |
59 |
| Separation of Concerns | A design principle suggesting that each module or component should have a single responsibility or concern, enhancing clarity and maintainability. | |
| ... |
... |
@@ -60,7 +60,6 @@ |
| 60 |
60 |
| [[Setter Injection|doc:Software Engineering.Architecture.Dependency Injection.Types of Dependency Injection.WebHome]] | A type of dependency injection where a dependency is provided to an object through a setter method. | |
| 61 |
61 |
| Snapshot | A saved state of a system or data at a specific point in time. Can be used for rollbacks. | |
| 62 |
62 |
| Software Engineer | Technical expert with in-depth knowledge in many areas, including high-level topics such as software architecture and system design. | |
| 63 |
|
-| Specification | A detailed description of the requirements under which a user story is considered complete. Much more detailed than the original user story. | |
| 64 |
64 |
| Static | Behaviors/properties determined before or at compile time. Examples: static code analysis tools inspect source code; statically-typed languages determine an object's type at compile time. | |
| 65 |
65 |
| [[Story/User Story|doc:Software Engineering.Agile.Extreme Programming.Planning Game.WebHome]] | See link. | |
| 66 |
66 |
| System | Entirety of software components designed to work together effectively in a production environment. | |
| ... |
... |
@@ -69,7 +69,6 @@ |
| 69 |
69 |
| Test-Driven Development (TDD) | A development approach where code is written in small increments, with tests defining functionality written at the beginning of each coding iteration. | |
| 70 |
70 |
| Test Suite | The sum of all the test code used to check that a system meets its requirements. | |
| 71 |
71 |
| Unit | The smallest testable part of an application. This is often a single class, method or module, but can also be a small cluster of tightly coupled classes or functions that together perform a specific functionality. | |
| 72 |
|
-| [[Velocity|doc:Software Engineering.Agile.Extreme Programming.Planning Game.Agile and Data.WebHome]] | See link. | |
| 73 |
73 |
| Virtual Machine (VM) | A software emulation of a physical computer, able to run its own OS and applications as if it were a separate physical machine. | |
| 74 |
74 |
| [[Waterfall|doc:Software Engineering.Agile.Problems of Waterfall.WebHome]] | See link. | |
| 75 |
75 |
| Wiring | The process conducted by the IoC container to create and inject dependencies, facilitating application startup. | |
