量化系统难题2_结构 关于做量化系统遇到的难题系统内各种类方法的问题前言时光飞逝转眼间几小时就过去了而我却没有研究怎么改好数据而是在这写系统结构的问题。这是为什么呢因为我实在没头绪不如先把这篇博客写好。难题对于一个经验丰富的开发者来说这应该不是什么难题但是对我来说是个问题。问题是这样的我的目的是建立一个日k级别的量化分析系统能够做到市场数据获取策略回测策略定义指标定义结果可视化等等功能。由于这是我第一次做包含这么多东西的项目所以就在类方法之间的相互依赖关系这个问题上犯了难。有哪些问题呢举几个例子数据获取我定义了两个类一个是基于akshare做的数据爬取fetcher类一个是负责本地数据管理的local_storage类此刻我定义一个数据获取方法get_data我该定义在哪怎样合理复用这两个类中的方法如果我更新了数据爬取的方法会不会对所有依赖它的方法造成影响类似的我又定义了一个批量获取数据的方法此时我是否要复用get_data如果不复用get_data的话一般是需要对获取过程做单独的优化比如数据获取时优先使用哪个源。思考做这种问题其实是一种思维的转变面向过程是一条线如获取数据→回测策略可选→可视化分析可选→根据策略生成买卖点创建一个文件从头写到尾就可以解决问题。但是这种模式在需要测试不同的策略的时候就会出现问题这也就催促我们把各种方法封装好。而面向对象则是一张网每一个步骤都可能调用上一步的任何一个方法这是不止是对代码能力的考验也是对系统整体架构思路清晰与否的考验。当时想着做这个系统之前其实我只是想做个选股器但是做个选股器就需要检验策略检验策略又需要数据检验结果又需要可视化数据存储形式需要优化数据也需要增量更新回测又需要高效率选股结果又需要生成个报告生成报告又需要接入大模型大模型报告中间又需要加入图表没完没了了某种角度上这个项目名称称为apeiria_stock还真没毛病因为apeiria寓意为无限嘛各种问题没完没了也是一种无限。至于为什么名叫apeiria_stock其实很简单因为流景之海的艾佩莉娅这个游戏剧情我很喜欢自然也就把女主的名字拿来用了。本文配图使用 Avilia Blog Illustrations 流程生成。