Towards VirtualShip v1 #195
Description
Summary
We now have a design doc for VirtualShip (#194, thanks @VeckoTheGecko for initiating the discussion and writing it up) where we outlined our vision for the project.
It seems like a good idea at this point to aim for a v1 release in the coming months, where changes to the codebase are mostly steered by the decisions made collectively in the design document.
A lot of the decisions in the design doc were made with the aim of making the code more flexible and organised rather than necessarily introducing functionality. I see v1 as being a stable, nice-to-work-with platform from which VirtualShip can then continue to be iterated on functionality-wise in the future.
Actions
New v1-dev branch
I will make a new v1-dev branch, into which we can start to merge v1 related contributions.
Next steps
I will kick things off by working on refactoring the instruments logic. @VeckoTheGecko and I met offline earlier this week and decided that there is substantial scope to reorganise, aiming for a structure where parent instrument class(es) contain logic applicable to all instruments and then at a lower level each individual instrument class has the specific methods it needs. Restructuring the data fetching will probably fall into this as well.
This will hopefully lead to easier implementation of new instruments going forward, for example, if say only a new instrument child class needs to be defined each time. This can then slot into the rest of the code and make it a more modular system. At the moment quite a few changes are required across the codebase with each new instrument.
Refactoring the instruments will then be followed by updated instrument testing.