量化系统难题2_结构

关于做量化系统遇到的难题，系统内各种类，方法的问题

前言

时光飞逝，转眼间几小时就过去了，而我却没有研究怎么改好数据，而是在这写系统结构的问题。这是为什么呢？因为我实在没头绪，不如先把这篇博客写好。

难题

对于一个经验丰富的开发者来说，这应该不是什么难题，但是对我来说是个问题。问题是这样的，我的目的是建立一个日k级别的量化分析系统，能够做到市场数据获取，策略回测，策略定义，指标定义，结果可视化，等等功能。由于这是我第一次做包含这么多东西的项目，所以就在类，方法之间的相互依赖关系这个问题上犯了难。

有哪些问题呢？举几个例子，数据获取我定义了两个类，一个是基于akshare做的数据爬取fetcher类，一个是负责本地数据管理的local_storage类，此刻我定义一个数据获取方法get_data我该定义在哪，怎样合理复用这两个类中的方法？如果我更新了数据爬取的方法，会不会对所有依赖它的方法造成影响？

类似的，我又定义了一个批量获取数据的方法，此时我是否要复用get_data？如果不复用get_data的话，一般是需要对获取过程做单独的优化，比如数据获取时优先使用哪个源。

思考

做这种问题其实是一种思维的转变，面向过程是一条线，如：获取数据→回测策略（可选）→可视化分析（可选）→根据策略生成买卖点，创建一个文件从头写到尾就可以解决问题。但是这种模式在需要测试不同的策略的时候就会出现问题，这也就催促我们把各种方法封装好。

而面向对象则是一张网，每一个步骤都可能调用上一步的任何一个方法，这是不止是对代码能力的考验，也是对系统整体架构思路清晰与否的考验。

当时想着做这个系统之前，其实我只是想做个选股器，但是做个选股器就需要检验策略，检验策略又需要数据，检验结果又需要可视化，数据存储形式需要优化，数据也需要增量更新，回测又需要高效率，选股结果又需要生成个报告，生成报告又需要接入大模型，大模型报告中间又需要加入图表，没完没了了，某种角度上，这个项目名称称为apeiria_stock还真没毛病，因为apeiria寓意为无限嘛，各种问题没完没了也是一种无限😂。至于为什么名叫apeiria_stock，其实很简单，因为流景之海的艾佩莉娅这个游戏剧情我很喜欢，自然也就把女主的名字拿来用了。