| ... |
... |
@@ -8,7 +8,7 @@ |
| 8 |
8 |
| [[Agile|doc:Software Engineering.Agile.WebHome]] | See link. | |
| 9 |
9 |
| 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)`. | |
| 10 |
10 |
| 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. | |
| 11 |
|
-| 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 |
+| Behavior | Counterpart to implementation. It refers to the externally visible actions performed by a component. For example: A class may have the public method `sort(Collection: SomeCollection)`, which says what it does, but no implementation details like what concrete sorting algorithm or private methods are used. | |
| 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. | |
| ... |
... |
@@ -59,8 +59,10 @@ |
| 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'. | |
| 62 |
62 |
| Requirement | Statement of what a software must be capable of doing, often outlining features, constraints, and success criteria. | |
| 63 |
63 |
| Resources | Refers to the assets used in the project, including time, money, staff, and effort. | |
|
65 |
+| Restructuring | Modifying code to improve its quality. | |
| 64 |
64 |
| 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. | |
| 65 |
65 |
| Rollback | The act of returning a system or data to a previous state, often using a snapshot. | |
| 66 |
66 |
| Rotting Code | Code that is increasingly difficult to maintain due to multiple changes that accumulate technical debt by not following best practices. | |
| ... |
... |
@@ -90,4 +90,5 @@ |
| 90 |
90 |
| [[Velocity|doc:Software Engineering.Agile.Extreme Programming.Planning Game.Agile and Data.WebHome]] | See link. | |
| 91 |
91 |
| 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. | |
| 92 |
92 |
| [[Waterfall|doc:Software Engineering.Agile.Problems of Waterfall.WebHome]] | See link. | |
|
95 |
+| Whispers | Vague comments in the source code that imply code problems without clearly explaining or addressing them. | |
| 93 |
93 |
| Wiring | The process conducted by the IoC container to create and inject dependencies, facilitating application startup. | |
