There is an effort underway to significantly refactor the code-base to be organized as "modules".
Background
Most of Braid's code is organized around technical layers ("views", "client-side-state", "websocket-message-handlers", "db", etc.). Adding a feature (such as, say, "starring a thread") involves changes throughout the entire stack, and the code being peppered throughout multiple files:
server client
http db email ui ....
| | | | |
emoji | e | m | o | ji |
| | | | |
| | | | |
| | | | |
search | s | e | a | rch |
| | | | |
| | | | |
.... | | | | |
"Modules" involves re-factoring the code so that each "feature" lives in its own folder. New functionality would be an addition of code, rather than a modification of previous code ("open to extension, closed to modification", "aspect oriented programming").
msgs db ui email
________________________________________________
emoji e mo ji
________________________________________________
search s e a rch
________________________________________________
/src
/braid
/core
...lots of stuff here, organized similarly to now, smaller as we extract into modules
/search
...one or more files, organized as necessary
/emoji-provider
/emoji-one
/file-upload
/file-upload-search
/dropbox-file-upload
/oauth-provider
/github-oauth
/google-oauth
... (lots of other modules)
One way to think about it is: currently, our separation-of-concerns is based only on "technical concerns", whereas the change to "modules" would add "product functionality" as concerns as well.
Motivations
Modules should hopefully:
make it easier to understand the system by better separation-of-concerns
make it easier to add new functionality without regressions
make it easier for new developers to add features
lead to "better" code (less coupling, more pleasant APIs, etc.)
make testing easier
foster the development of optional non-core functionality
Progress
We've thought a lot about the "api" of modules, and iterated it multiple times. Improvements to how "modules work" will continue, and tracked in this milestone and this issue .
We've transitioned the code into a core module, and extracted a few modules out of core (quests and various emoji modules).
The Braid Module Graph project exists to help visualize what modules could be extracted and how they could be related.
jamesnvc
commented
5 years ago
There is an effort underway to significantly refactor the code-base to be organized as "modules".
Background
Most of Braid's code is organized around technical layers ("views", "client-side-state", "websocket-message-handlers", "db", etc.). Adding a feature (such as, say, "starring a thread") involves changes throughout the entire stack, and the code being peppered throughout multiple files:
"Modules" involves re-factoring the code so that each "feature" lives in its own folder. New functionality would be an addition of code, rather than a modification of previous code ("open to extension, closed to modification", "aspect oriented programming").
One way to think about it is: currently, our separation-of-concerns is based only on "technical concerns", whereas the change to "modules" would add "product functionality" as concerns as well.
Motivations
Modules should hopefully:
Progress
We've thought a lot about the "api" of modules, and iterated it multiple times. Improvements to how "modules work" will continue, and tracked in this milestone and this issue .
We've transitioned the code into a
coremodule, and extracted a few modules out ofcore(questsand variousemojimodules).The Braid Module Graph project exists to help visualize what modules could be extracted and how they could be related.
Next:
questsandemojiaccording to the changesModules