对于一个开源 Python 量化交易平台项目的建议有哪些？ 第1页

主要看你的定位在哪里。简单说，作为一个业余时间的练手就是很赞的作品，但要定位成专业交易平台则问题很多：

• Python的问题不仅仅在于延迟性能，更致命的是这个弱类型语言很难做编译期静态检测，系统复杂以后很容易写出 bug。这对于交易系统这种对系统稳定性有苛刻要求的系统来说是很难接受的。
• 你的架构看起来是图形界面和策略代码都跑在一个进程里，如果这是真的那就意味着任何一个 UI 上的问题都有可能导致交易策略崩溃。看你的截图，开发这么复杂的图形界面要想不出问题，很难。
• 截图上还可以看出这个系统运行起来会同时跑很多个 Order。Order 多了以后首先是上面说的稳定性隐患很致命，你的系统一旦崩溃，那些还在运行的 Order 估计多半要手动清理了，手慢了可能会有直接损失。另外系统需要实时收发行情数据来更新界面，如果架构上没有解藕的话，很可能意味着界面更新慢会阻塞网络数据的收发（俗称 backpressure）。
• 事件驱动引擎要做好并不容易。比如有名的 Esper 就是相当复杂的系统（而且用户体验还很差）。用 Python 写，我觉得难度更加大。

基本上，从计算机系统的角度考虑，我觉得最好还是不要定位成一个大而全的一体化交易系统为好。你作为一个交易员，如果能把自己熟悉的业务部分的若干模块提炼出来做精就很有价值了。

开源协议 GPL 系是大忌，慎入。GPL 的意思是用了你的代码以后，自己的二次开发也要强制开源，这意味着所有的交易策略都要开源，那就没人敢用你的东西了。

如果有兴趣在系统开发上向前走，几点建议是：

• 核心策略相关的代码用强类型语言编写，做足检查和测试
• 至少在进程粒度上把图形界面和交易策略分开
• 现在的图形界面是 Web 的天下了，试着学学 HTML/CSS/Javascript。

看到题主的回答中这一段非常有感触：

但是在实际运用中，交易团队表达了一个强烈的观点：这个平台实在是太难用了！

1. 由IT团队设计的API功能非常强大，但是也太过繁琐，导致学习曲线极为陡峭

2. 为了追求速度，没有设计原生GUI（本来就为了在Linux服务器上跑），但是今天绝大多数的非超高频（追求微秒级延迟的那种）交易策略，几乎都需要有人实时监控，你总不能让交易员盯着个linux shell上不断print出来的内容或者盘中去翻日志吧，这个运维风险就扛不起。尽管可以作为插件的形式开发GUI，但C++本身的GUI开发还是较为复杂的，非专业IT很难搞的定。

3. 交易员团队的需求变化很快，通常等不及IT去排班开发，最好是今天收盘有个点子，明天开盘就能开始接实盘数据验证，没问题后天就能上实盘。比如去年四季度的分级基金套利机会就是稍纵即逝，那段时间如果能快速开发完成一套专门的监控套利系统，抓住的利润绝对会比用excel接wind数据来的多不少。

4. 某些业务逻辑确实太过复杂，交易员想解释让IT明白，无奈IT并不是太擅长某些金融领域（比如期权高频套利的整个业务框架），交流成本太高。

这可以说是纯 IT 背景的人入行会遭遇的最大的挑战，一个 Pure IT Role 其实是很难适应交易这个行业的。干这行是非常需要复合型人才的，IT 如果只满足于在自己一亩三分地恪守软件开发的职责，后果就是 Trader 们被逼自己写代码，这实在是一出悲剧。