| ... |
... |
@@ -2,7 +2,7 @@ |
| 2 |
2 |
|
| 3 |
3 |
| -------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | |
| 4 |
4 |
| **Term** | **Explanation** | |
| 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 shared code. Duplication across multiple functions can often be resolved by creating an 'abstraction' - an additional function containing the duplicated code. | |
|
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 |
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)`. | |
| ... |
... |
@@ -46,10 +46,9 @@ |
| 46 |
46 |
| Magic | Code that performs complex tasks while abstracting away the complexity, presenting a simple interface to the user. | |
| 47 |
47 |
| Manager | Individuals responsible for planning, organizing, leading, and controlling a software project's resources, schedule, and deliverables to meet stakeholder expectations. | |
| 48 |
48 |
| Operating System (OS) | The foundational system software that manages and coordinates all computer resources. Examples are Windows, MacOS and Linux. | |
| 49 |
|
-| Overloading | Some programming languages offer the feature of overloading, which means that two operators with the same name can still be distinguished if they have different signatures. For example, these two functions are overloaded: `tripleNumber(n: float)` and `tripleNumber(n: int)`. | |
| 50 |
50 |
| Pain | An unpleasant experience caused by unnecessary efforts that could have been mitigated with better design of the original code. | |
| 51 |
51 |
| [[Pair Programming|doc:Software Engineering.Agile.Extreme Programming.Pair Programming.WebHome]] / Pairing (up) | See link. | |
| 52 |
|
-| Physical | The counterpart to "logical". Refers to hardware. For example, physically deleting a file means removing it from the disk. | |
|
51 |
+| Physical | Counterpart to logical. Refers to hardware. For example, physically deleting a file means removing it from the disk. | |
| 53 |
53 |
| Points / Story Points | A unit of measure used to estimate the effort required to complete a user story. See also [[here|doc:Software Engineering.Agile.Extreme Programming.Planning Game.Effort Estimation.WebHome]]. | |
| 54 |
54 |
| Problem Domain | The language/terminology used to describe the software requirements ("the problems") from the perspective of non-technical stakeholders. | |
| 55 |
55 |
| Production Code | Code that comprises the functioning part of an application, as opposed to test code. | |
