Atm the moment, the code in the repo is organically structured. I don't mean that it's a mess, a little bit maybe, but it's kind of like a town that outgrew its initial plan.
Utilities exist at various locations (with potential duplicates), as well as commands, and js code that is just... well, code! The code makes sense once you get to know it, but it might look a bit intimidating to newcomers. As it becomes more complex, we can expect that even people familiar with it only understand a part of it. Working on the code becomes harder, less efficient, less agile, and eventually quality is capped because developing is obstructed by the fear of breaking other stuff. The code should be as simple as possible for like 1000 reasons. It's not too bad atm, but we should do something about it so that it's not considerably bad in like 6 months.
I don't have a plan for an aggressive refactor to fix this, nor I know what the perfect structure should be, I simply would like to suggest that we pick a philosophy, and organically evolve down the path it lays. One such philosophy could be the separation of data, contracts, js code that wraps contracts, and commands that wrap js code that interacts or observes contracts, into well defined and as-minimal-as-possible "modules".
With a chosen philosophy, we could start making concise issues that takes the code in the intended direction, without the requirement of having a master evil plan. No Cathedral. Just the good old every day Bazaar. I bet it even turns out to be an easy task after a couple of iterations.
I would start by separating deployment data from configuration files, and even perhaps deleting configuration files. Then, we could separate code intended for observing the system, from code intended for interacting with the system as a user, and from code intended for interacting with the system as an owner, or dao.
Something like that. Or we could just continue to organically react to whatever comes up, but the code will not be easy to catch on.
theethernaut
commented
3 years ago 
Atm the moment, the code in the repo is organically structured. I don't mean that it's a mess, a little bit maybe, but it's kind of like a town that outgrew its initial plan.
Utilities exist at various locations (with potential duplicates), as well as commands, and js code that is just... well, code! The code makes sense once you get to know it, but it might look a bit intimidating to newcomers. As it becomes more complex, we can expect that even people familiar with it only understand a part of it. Working on the code becomes harder, less efficient, less agile, and eventually quality is capped because developing is obstructed by the fear of breaking other stuff. The code should be as simple as possible for like 1000 reasons. It's not too bad atm, but we should do something about it so that it's not considerably bad in like 6 months.
I don't have a plan for an aggressive refactor to fix this, nor I know what the perfect structure should be, I simply would like to suggest that we pick a philosophy, and organically evolve down the path it lays. One such philosophy could be the separation of data, contracts, js code that wraps contracts, and commands that wrap js code that interacts or observes contracts, into well defined and as-minimal-as-possible "modules".
With a chosen philosophy, we could start making concise issues that takes the code in the intended direction, without the requirement of having a master evil plan. No Cathedral. Just the good old every day Bazaar. I bet it even turns out to be an easy task after a couple of iterations.
I would start by separating deployment data from configuration files, and even perhaps deleting configuration files. Then, we could separate code intended for observing the system, from code intended for interacting with the system as a user, and from code intended for interacting with the system as an owner, or dao.
Something like that. Or we could just continue to organically react to whatever comes up, but the code will not be easy to catch on.