search

maxholloway / Backtest.jl

Very simple event-based backtesting platform.
MIT License
0 stars 0 forks source link

Utils or No Utils? #15

Open maxholloway opened 4 years ago

maxholloway commented 4 years ago

To Utils or Not to Utils?

Background

In the first making of this package, there was a Utils module that was intended to house common high-level behavior (such as cross-over events between two different fields). This module sat on top of the main Backtest module. Now we are stuck at a crossroads: do we include high-level functionality in our Backtest API ("Pro-Utils"), or do we split this into another project ("Anti-Utils")?

Pro-Utils

  1. I have a strong disposition towards 1-stop-shops. If I create another package, then this will require users to keep track of two separate packages. That thought makes me cringe.
  2. It would be easy enough to just add another sub-module to the Backtest module called Utils, which would depend on the types from the Backtest main module. This would be easy-enough for users to work with.
  3. It would be easier to develop Utils in the same package, probably for multiple reasons. One reason is that we currently don't know the Utils interface. So what happens if we want to add a feature to Utils, but this feature requires access to a low-level data-member in Engine? While this is unlikely, it's not impossible, and this problem would be really cumbersome if we split up the packages. We'd need to first modify the Backtest.jl API to give access to the Engine member, meaning that the tail (Utils) was wagging the dog (Backtest.jl). After this API change, we'd need to update our Backtest.jl version in Utils, then hope that the new API fix was adequate. This process would repeat any time we make low-level calls. Not great!

Anti-Utils

  1. Backtest has already become bloated compared to some other Julia packages. It may be a better idea to stop adding stuff to this package, and instead break off a high level wrapper that has Backtest.jl as a dependency.
  2. Eventually Utils could provide a nice layer between the low-level backtesting that takes place in Backtest.jl and the high-level experimentation that Backtest.jl would be used for.
  3. It may be difficult to develop on Backtest.jl as it becomes larger and larger. If we do create a Utils submodule, the Backtest.jl file will become even larger. Perhaps a big file of code isn't a big deal? Personally I don't mind it that much, so long as my editor has code collapsing.

Current Conclusion

There are a lot of questions around architecture (see #14). For now, since there is so little decisiveness on what is the best move, it may be best to just not develop the Utils code as a part of Backtest.jl, and then decide later. For the near-future, most of my dev time will go toward Backtest.jl (including its API), so more details are to come on this.

maxholloway commented 4 years ago

Decided to add Utils for now; see issue #17 and PR #18.