| ... |
... |
@@ -3,11 +3,13 @@ |
| 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. | |
| 6 |
6 |
| [[Agile|doc:Software Engineering.Agile.WebHome]] | See link. | |
| 7 |
7 |
| 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)`. | |
| 8 |
8 |
| 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. | |
| 9 |
9 |
| 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. | |
| 10 |
10 |
| 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. | |
| 11 |
11 |
| Compile Time | The period when the code is compiled. Often used to distinguish from runtime. | |
| 12 |
12 |
| 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. | |
| 13 |
13 |
| [[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. | |
| ... |
... |
@@ -17,6 +17,7 @@ |
| 17 |
17 |
| [[Continuous Integration|doc:Software Engineering.Agile.Extreme Programming.Continuous Integration.WebHome]] (CI) | See link. | |
| 18 |
18 |
| Daemon | A program running in the background of a system, often without a GUI. | |
| 19 |
19 |
| 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. | |
| 20 |
20 |
| 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. | |
| 21 |
21 |
| 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. | |
| 22 |
22 |
| [[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. | |
| ... |
... |
@@ -49,6 +49,7 @@ |
| 49 |
49 |
| Rollback | The act of returning a system or data to a previous state, often using a snapshot. | |
| 50 |
50 |
| Rotting Code | Code that is increasingly difficult to maintain due to multiple changes that accumulate technical debt by not following best practices. | |
| 51 |
51 |
| Runtime | The period when the code is being executed. Often used to distinguish from compile time. | |
|
55 |
+| Scope / Project Scope | The extent of features that must be implemented to deliver a project. | |
| 52 |
52 |
| Security | Measures implemented to protect systems from threats, unauthorized access, and vulnerabilities. This includes, but is not limited to, authentication, authorization, and encryption. | |
| 53 |
53 |
| 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. | |
| 54 |
54 |
| Separation of Concerns | A design principle suggesting that each module or component should have a single responsibility or concern, enhancing clarity and maintainability. | |
| ... |
... |
@@ -63,6 +63,7 @@ |
| 63 |
63 |
| 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. | |
| 64 |
64 |
| Test Suite | The sum of all the test code used to check that a system meets its requirements. | |
| 65 |
65 |
| 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. | |
|
70 |
+| [[Velocity|doc:Software Engineering.Agile.Extreme Programming.Planning Game.Agile and Data.WebHome]] | See link. | |
| 66 |
66 |
| 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. | |
| 67 |
67 |
| [[Waterfall|doc:Software Engineering.Agile.Problems of Waterfall.WebHome]] | See link. | |
| 68 |
68 |
| Wiring | The process conducted by the IoC container to create and inject dependencies, facilitating application startup. | |
