Changes for page Glossary

Last modified by chrisby on 2024/09/19 10:50

From version 18.54
edited by chrisby
on 2023/12/09 12:27
Change comment: There is no comment for this version
To version 18.59
edited by chrisby
on 2024/01/21 11:34
Change comment: There is no comment for this version

Summary

Details

Page properties
Content
... ... @@ -12,6 +12,7 @@
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. |
15 15  | Compile Time | The period when the code is compiled. Often used to distinguish from runtime. |
16 16  | 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. |
17 17  | [[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. |
... ... @@ -50,6 +50,7 @@
50 50  | Logical | The counterpart to physical. The abstract representation of something in software. For example, deleting a file from the desktop only logically deletes it, but actually moves it to the Recycle Bin, while the file physically remains on disk until the Recycle Bin is emptied. |
51 51  | Magic | Code that performs complex tasks while abstracting away the complexity, presenting a simple interface to the user. |
52 52  | Manager | Individuals responsible for planning, organizing, leading, and controlling a software project's resources, schedule, and deliverables to meet stakeholder expectations. |
54 +| Object | A distinct entity that encapsulates data and behavior while providing an API for operations or indirect interaction with its data. Often an object is constructed from a class that has private fields while providing some private methods and some public functions for interaction. For example: `board = new ChessBoard(); board.printPossibleMoves(); board.doMove(...);` |
53 53  | Operating System (OS) | The foundational system software that manages and coordinates all computer resources. Examples are Windows, MacOS and Linux. |
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. |
... ... @@ -79,6 +79,7 @@
79 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. |
80 80  | 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. |
81 81  | 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. |
84 +| [[Story-Driven Development|doc:Software Engineering.Agile.Extreme Programming.Planning Game.WebHome]] | See link. |
82 82  | [[Story / User Story|doc:Software Engineering.Agile.Extreme Programming.Planning Game.WebHome]] | See link. |
83 83  | 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]]. |
84 84  | 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]]. |