mirror of
https://github.com/RPG-Research/bcirpg.git
synced 2024-04-16 14:23:01 +00:00
Updated UML Guidelines (markdown)
parent
d23d832380
commit
4d89ccb740
@ -2,4 +2,33 @@ UML Guidelines
|
|||||||
|
|
||||||
Unified Modeling Language (UML) is used as part of the design phase of all our projects. 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 tends to lead to 10% new features code (forward progression of the code base features and scaling), 85% debugging/fixing (trying to maintain/fix the existing code base), <5% documentation = garbage code that can't be scaled, or maintained when constantly changing developer eyeballs/brains. The design-first approach, if correctly implemented with Object Oriented principles typically leads to 10-20% documentation, 20-50% new features coding iteration (forward progression of the code base), 20-40% debugging/iteration (trying to maintain/fix the existing code base), and is much easier to collaborate, maintain, and support over many years and many different eyeballs and brains.
|
Unified Modeling Language (UML) is used as part of the design phase of all our projects. 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 tends to lead to 10% new features code (forward progression of the code base features and scaling), 85% debugging/fixing (trying to maintain/fix the existing code base), <5% documentation = garbage code that can't be scaled, or maintained when constantly changing developer eyeballs/brains. The design-first approach, if correctly implemented with Object Oriented principles typically leads to 10-20% documentation, 20-50% new features coding iteration (forward progression of the code base), 20-40% debugging/iteration (trying to maintain/fix the existing code base), and is much easier to collaborate, maintain, and support over many years and many different eyeballs and brains.
|
||||||
|
|
||||||
We follow the principles of Object Oriented Design (OOD), even when not using OO languages, and design-first approach means it takes longer before we actually write working code (in the early phases), but leads to a much more sustainable, scalable, distributable, flexible, and manageable product overall.
|
We follow the principles of Object Oriented Design (OOD), even when not using OO languages, and design-first approach means it takes longer before we actually write working code (in the early phases), but leads to a much more sustainable, scalable, distributable, flexible, and manageable product overall.
|
||||||
|
|
||||||
|
We also use UML as a visual aide to help with the design documentation.
|
||||||
|
|
||||||
|
If you wish to contribute coding to this project, then we ask you to please make yourself at least somewhat familiar with these OO and UML principles.
|
||||||
|
|
||||||
|
We REQUIRE you to document your code proposals BEFORE you submit actual code. At the bare minimum we want to see:
|
||||||
|
Narrative User Use Case explaining what you want a feature to do from the user perspective.
|
||||||
|
Narrative Developer Use Case explaining the "under the hood" goals of your code, what you expect it to do, how you expect it to do it, etc.
|
||||||
|
A general workflow diagram to go with each narrative.
|
||||||
|
A UML class diagram to accompany the code proposal.
|
||||||
|
You are of course welcome to write your code, trying to figure this out, but before you try submitting it to our branch, you MUST PROVIDE THIS DOCUMENTATION BEFORE WE CAN ACCEPT IT.
|
||||||
|
|
||||||
|
Here are some recommended resources:
|
||||||
|
|
||||||
|
Online:
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Books:
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
|
Loading…
Reference in New Issue
Block a user