Before I implement any new features I would like to review the entire code base as it is right now, and if needed, refactor it. There are several reasons why:
Even though adding new code feels fast enough, it doesn't always feel right. Duplicated logic can be spotted easily and the separation between sub-modules is questionable.
The amount of features that will be in the editor in the near-future will be far more than the current small set of features available. It will be important that it is very obvious where each new feature fits within the code base, without infecting any other code.
We also have to start thinking on how to add Unit Tests, to get the most use of it, this way we could rely on writing unit tests alongside the features and have a fairly good estimation of how well it works.
MVP isn't always respected, so we need to make sure that all our calculations happen separately. GUI can be a huge black hole, as the requirements often change. Therefore it is important that we only have to deal with how to represent it for the user, rather than what.
Based on the current code and the features that I have in mind, it would also not be bad idea to think very carefully about a decent code-base structure that is resistant in the long-term, as right now that really feels wonky, to say the least.
Before I implement any new features I would like to review the entire code base as it is right now, and if needed, refactor it. There are several reasons why:
Based on the current code and the features that I have in mind, it would also not be bad idea to think very carefully about a decent code-base structure that is resistant in the long-term, as right now that really feels wonky, to say the least.