RPGResearch/bcirpggithubmirror
RPGResearch/bcirpggithubmirror
7
0
Fork 0
mirror of https://github.com/RPG-Research/bcirpg.git synced 2024-04-16 14:23:01 +00:00
Code Issues Packages Projects Releases Wiki Activity

Updated UML Guidelines (markdown)

RPG Research 2023-01-15 11:44:45 -08:00
parent f5dd9afee3
commit 948759f88a
1 changed files with 7 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

7
UML-Guidelines.md

@ -2,6 +2,13 @@ UML Guidelines
General Flowcharts and Unified Modeling Language (UML) is used as part of the design phase of all our projects.
This page is to help define any "House Rules" we have decided upon with our implementation of UML visual design documentation.
UML is a very flexible language, and as such there are not always hard and fast rules about which symbols are used in which way consistently. Each organization over time ends with their own "dialect" of UML implementation UI.
In role-playing game terms think of it this way.
The UML specifications are the "Rules As Written" (RAW) of the role-playing game core systems book. Over time various supplement rules are published, that may be added as additional RAW or excluded as "not core rules". In some cases the added rules might conflict with the core rules, requiring each group to decide which of the rules they want to follow and which t exclude.
Additionally, during game play, situations come up that are not clearly defined in the core or supplementary rules, so the Game Master (and group) need to figure out a way to resolve the situation. These decisions in the group are generally known as "House Rules" in the TRPG world.
While it has become (arguably erroneously) popular since about 2010-2015+ to regress back to code-first, design-later, this invariably leads to unscalable and unsustainable projects. The code-first approach works okay for small, non-distributed projects, the "quick and dirty" code. But for more complex projects, the code-first approach invariably leads to chaos the moment you try to distribute the work across other developers. The code-first approach gives the illusion of more progress sooner, and does in the short term, but in the long run begins to bog down horribly, leadin to (at best) only being able to release code for 10% of the time toward new features and improvements code (forward progression of the code base features and scaling), 85% debugging/fixing (trying to maintain/fix the existing code base), <5% documentation. This all leads to an overall garbage codebase that can't be scaled, or maintained, especially when constantly changing developer eyeballs/brains. Typically unable to move beyond 3.x iterations without major overhauls.
The design-first approach, if correctly implemented with Object Oriented principles, typically leads to much more sustainable and distributable codebase over time. This usually means it works out to time spent around: 10-20% on documentation, 20-50% toward new features coding iteration (forward progression of the code base), 20-40% debugging/iteration (trying to maintain/fix the existing code base), and is SO much easier to collaborate, maintain, and support over many years and many different eyeballs and brains.