| ... |
... |
@@ -12,7 +12,6 @@ |
| 12 |
12 |
| Best Practices | Widely accepted guidelines designed to enhance programming productivity and code quality. Adherence can prevent many potential issues. | |
| 13 |
13 |
| Business | Non-technical decision makers in the organization developing the software. | |
| 14 |
14 |
| Business Value | The worth of a feature in terms of its benefit to the business. | |
| 15 |
|
-| Clean Code | A term coined by Robert. C Martin, see [[book recommendations|doc:Main.Recommended Books.WebHome]]. It means code that is readable, which means easy to understand and also maintainable, which means easy to change. | |
| 16 |
16 |
| Compile Time | The period when the code is compiled. Often used to distinguish from runtime. | |
| 17 |
17 |
| Concretion | The counterpart to 'abstraction'. Concretion is also known as 'implementation'. In OOP, it 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. | |
| 18 |
18 |
| [[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. | |
| ... |
... |
@@ -65,7 +65,7 @@ |
| 65 |
65 |
| Requirement | Statement of what a software must be capable of doing, often outlining features, constraints, and success criteria. | |
| 66 |
66 |
| Resources | Refers to the assets used in the project, including time, money, staff, and effort. | |
| 67 |
67 |
| Restructuring | Modifying code to change its functionality, or to improve its quality ('refactoring') or performance ('performance optimization'). | |
| 68 |
|
-| 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 |
+| 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. | |
| 69 |
69 |
| Rollback | The act of returning a system or data to a previous state, often using a snapshot. | |
| 70 |
70 |
| Rotting Code | Code that is increasingly difficult to maintain due to multiple changes that accumulate technical debt by not following best practices. | |
| 71 |
71 |
| Runtime | The period when the code is being executed. Often used to distinguish from compile time. | |
| ... |
... |
@@ -80,11 +80,10 @@ |
| 80 |
80 |
| Specification | A detailed technical description of the requirements under which a user story is considered complete. Much more detailed than the original user story. | |
| 81 |
81 |
| 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. | |
| 82 |
82 |
| 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. | |
| 83 |
|
-| [[Story-Driven Development|doc:Software Engineering.Agile.Extreme Programming.Planning Game.WebHome]] | See link. | |
| 84 |
84 |
| [[Story / User Story|doc:Software Engineering.Agile.Extreme Programming.Planning Game.WebHome]] | See link. | |
| 85 |
85 |
| 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]]. | |
| 86 |
86 |
| 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]]. | |
| 87 |
|
-| 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 |
+| System | Entirety of software components designed to work together effectively in a production environment. | |
| 88 |
88 |
| 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. | |
| 89 |
89 |
| Test Code | Code that tests the functionality of production code. Does not contribute to the operational aspects of an application. | |
| 90 |
90 |
| 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. | |
