| ... |
... |
@@ -54,16 +54,17 @@ |
| 54 |
54 |
| 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)`. | |
| 55 |
55 |
| Pain | An unpleasant experience caused by unnecessary efforts that could have been mitigated with better design of the original code. | |
| 56 |
56 |
| [[Pair Programming|doc:Software Engineering.Agile.Extreme Programming.Pair Programming.WebHome]] / Pairing (up) | See link. | |
|
57 |
+| Performance Optimization | Modifying code to enhance its execution speed, which may involve trade-offs at the expense of code quality. It is a subtype of 'Restructuring'. | |
| 57 |
57 |
| Physical | The counterpart to "logical". Refers to hardware. For example, physically deleting a file means removing it from the disk. | |
| 58 |
58 |
| 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]]. | |
| 59 |
59 |
| Problem Domain | The language/terminology used to describe the software requirements ("the problems") from the perspective of non-technical stakeholders. | |
| 60 |
60 |
| Production Code | Code that comprises the functioning part of an application, as opposed to test code. | |
| 61 |
61 |
| Programmer | Someone who writes and tests code. The knowledge level of a beginner. | |
| 62 |
|
-| Refactoring | Modifying code to improve its quality without changing its functionality. It is a subtype of 'Restructuring'. Often used as: 'to refactor code'. | |
|
63 |
+| Refactoring | Modifying code to improve its quality without changing its functionality. It is a subtype of 'Restructuring'. | |
| 63 |
63 |
| Requirement | Statement of what a software must be capable of doing, often outlining features, constraints, and success criteria. | |
| 64 |
64 |
| Resources | Refers to the assets used in the project, including time, money, staff, and effort. | |
| 65 |
|
-| Restructuring | Modifying code to improve its quality. | |
| 66 |
|
-| Return of Investment (RoI) | The ratio of the business value gained from implementing a story to the effort/cost involved. A higher RoI means that something is more worth implementing than something with a low RoI. | |
|
66 |
+| Restructuring | Modifying code to change its functionality, or to improve its quality ('refactoring') or performance ('performance optimization'). | |
|
67 |
+| Return of Investment (ROI) | The ratio of the business value gained from implementing a story to the effort/cost involved. A higher ROI means that something is more worth implementing than something with a low ROI. | |
| 67 |
67 |
| Rollback | The act of returning a system or data to a previous state, often using a snapshot. | |
| 68 |
68 |
| Rotting Code | Code that is increasingly difficult to maintain due to multiple changes that accumulate technical debt by not following best practices. | |
| 69 |
69 |
| Runtime | The period when the code is being executed. Often used to distinguish from compile time. | |
| ... |
... |
@@ -74,14 +74,15 @@ |
| 74 |
74 |
| [[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. | |
| 75 |
75 |
| Snapshot | A saved state of a system or data at a specific point in time. Can be used for rollbacks. | |
| 76 |
76 |
| Software Engineer | Technical expert with in-depth knowledge in many areas, including high-level topics such as software architecture and system design. | |
| 77 |
|
-| Solution Domain | The language/terminology used by technical experts to describe the technical solutions to the software requirements described by the problem domain. | |
| 78 |
|
-| Specification | A detailed description of the requirements under which a user story is considered complete. Much more detailed than the original user story. | |
|
78 |
+| Solution Domain | The language/terminology used by technical experts to describe the technical solutions to the software requirements defined by the problem domain. | |
|
79 |
+| Specification | A detailed technical description of the requirements under which a user story is considered complete. Much more detailed than the original user story. | |
| 79 |
79 |
| Stakeholders | Individuals with an interest in the success of a software project, which may include customers, developers, investors, externals and others who are affected by the projects outcome. | |
| 80 |
80 |
| 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. | |
|
82 |
+| [[Story-Driven Development|doc:Software Engineering.Agile.Extreme Programming.Planning Game.WebHome]] | See link. | |
| 81 |
81 |
| [[Story / User Story|doc:Software Engineering.Agile.Extreme Programming.Planning Game.WebHome]] | See link. | |
| 82 |
82 |
| Story Card | A physical card containing a user story and other relevant information such as an effort estimate and a business value. See also [[here|doc:Software Engineering.Agile.Extreme Programming.Planning Game.WebHome]]. | |
| 83 |
83 |
| Story Deck | A collection of story cards for capturing the requirements of a project. See also [[here|doc:Software Engineering.Agile.Extreme Programming.Planning Game.WebHome]]. | |
| 84 |
|
-| System | Entirety of software components designed to work together effectively in a production environment. | |
|
86 |
+| System | A set of software components designed to work together effectively in a production environment. It often refers to the software as a whole that can be utilized by end users. | |
| 85 |
85 |
| Technical Debt | The implicit cost of additional rework caused by choosing an easy solution now instead of using a better approach that would take longer. Often the result of poor design, testing, and refactoring. | |
| 86 |
86 |
| Test Code | Code that tests the functionality of production code. Does not contribute to the operational aspects of an application. | |
| 87 |
87 |
| 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. | |
