当前位置:  开发笔记 > 编程语言 > 正文

对于管理一个开源Python量化交易框架项目(vn.py)的建议有哪些?

回复内容:1.坚持遵循Wheaton法则Wheaton法则的中心思想是“Don’tbeadick”,意思是不要成为一个不顾别人感受的人。在这里,我想说的是,你要耐心对待你的开源项目的用户。2.不要害怕说“不”、“请提交测试”,“请修复{X}”等3.明智地选择合作伙伴如果你的项目已经增长到需要合作伙伴

回复内容:

1. 坚持遵循Wheaton法则


Wheaton法则的中心思想是“Don’t be a dick”,意思是不要成为一个不顾别人感受的人。在这里,我想说的是,你要耐心对待你的开源项目的用户。

2. 不要害怕说“不”、“请提交测试”,“请修复{X}”等

3. 明智地选择合作伙伴

如果你的项目已经增长到需要合作伙伴的地步,那么可以考虑让其他开发者来作为项目共同所有者或维护者。前提是,你要明智地选择这些人。
4.写好指导性文字

每一个开源项目有三样东西是少不了的:项目目标和方法的简要说明、如何参与和授权许可。最好把它们预先放在一个README里。

5.技术社区

想要一个人做完所有的事是很难的,特别是很多人都期待着你能拿出好的作品。

抓住任何一个机会寻找pull请求。集思广益的力量是无穷大的,所以无论何时何地我都会向技术社区的成员寻求意见,他们常常说的RFC我从来没听过,甚至有的时候他们会主动研究前端主题。


项目可以很容易地升级

随着项目中bug的修复和一些功能的改进,你需要发布另一个版本。需要注意的是:

1. 向后兼容

不要因为不向后兼容,而让用户重写大量代码。这样会让用户愤怒,继而抛弃你的项目。当然,你也不必像OpenJDK那样兼容15年前的产品。

2. 更新日志

有一个清晰明确的更新日志,需要包含:该版本发生了什么变化?会破坏用户现有项目的代码吗?等等。比如Twitter的做法:

  • 每修复一个bug,就在更新日志中写上一个简短的条目
  • 每添加一个功能,就简要描述一下并附上一些示例代码
  • 每改变一个API,就需要在日志中用粗体明确指出
如果你有多个分支,就需要为每个分支都写一份更新日志。

3. 版本标签

为你的项目的每一个版本打上一个标签,比如v1.0.0-alpha1、v1.0.0、v1.1.2,可以让你的用户很清晰地分辨出项目的版本。

4. 发布公告

项目发布后,接下来就需要为这个事件写一篇博文,或直接将公告发布到项目的邮件列表中。

在公告中需要说明这个项目有什么用,是否向后兼容,并给出更新日志的链接。

5. 项目状态标签

有些项目很长时间一直使用相同的版本号,比如1.1.0,而项目一直在改进。如果这是一个开发版本,你也需要通过标签来说明项目所处的开发阶段。比如:

  • 1.1.0.pre1
  • 1.1.0-alpha1
  • 1.1.0-SNAPSHOT
总之,你要确保项目有一个严格的版本命名规划。

四、使用GitHub

在GitHub上,你可以很容易地做下面的事情:

  • 发布你的项目
  • 浏览和搜索代码
  • 专注于项目issues
  • 参与贡献,合并用户的贡献
五、确保有一个为用户提供支持的地方

如果你的项目达到一定的普及程度,你就会不断收到用户的提问。你需要有一个收集和回答用户提问的地方,比如论坛、邮件列表等。只要有一个交流的地方,用户也可以彼此提供帮助。久而久之,就会形成一个很不错的社区。

六、项目传递

不排除这种情况——你可能会对项目维护失去兴趣,或者你换了一个新工作不再使用当前的项目了。你可以在邮件列表上公布,让其他开发者接管你的项目。在Github上项目所有权转移会更容易,尤其是在别人为你的项目引入了新功能后。

无论如何,不要让项目死掉。

七、总结

总之,在你打算发布开源产品时,请确保它有:

  • 清晰的依赖/安装说明
  • 至少有一个简短的文档/指南
  • 库中包含更改日志和相关标签
  • 一些关于支持语言、运行环境、工具版本、项目成熟度的信息
  • 邮件列表,供用户提问、相互帮助
八、最后

总之,要想让你的开源项目“发扬光大”,首先应该让它对用户更友好。除了项目文档外,其他事情花费不了多长时间。 先点个赞,题主看起来有大将风范 。
大概看了一下,抽象程度还太低,暴露了太多接口了,
建议1,首页的demo换一个,改成面向策略开发人员,而不是交易通道开发人员,目标人群很重要。
建议2,期货端ctp暂时够用了,很通用满足很多人了。
但股票端lts太小众,而且华宝太小家子气成不了大气候(客观吐槽),需要开发更多的股票broker,基础设施有了才能更好吸引人。
保持关注,找机会提交代码! 想到啥说啥:
  • 还是用Github好,受众会广一点(科学上网对程序员就不是个事啊)。最好文档准备中英文;这样受众更多。
  • 文档在README里面放链接,可以不限于放在github的wiki里面。文档写得好才会让开发人员感兴趣,让用户喜欢用。
  • 开源本身是没有功利性质的,开源社区也不是你指挥其他人去做事情。
  • 大部分情况是这样的:有人在Github看到你的项目觉得不错,但是有些地方自己觉得不爽,而且还想写代码。那么基本会fork一个,commit后发起pull request,或者不发pull request。。
  • 这样慢慢积累长期贡献代码的核心成员。而不是先在网上号召一堆人去做。你说他核心,他不写代码,最多也就是个友情支持。
感觉任务分派模式不好,如果是没有酬劳,感觉要是有人跳票(毕竟也不能保证他的代码风格很好,注释很完备),那么很容易就卡住;而且代码的质量其实也无法保证。

喜欢社区或者 news letter 之类的方式,或者固定的一些维护人员这种、

代码托管平台肯定是要的,但是开放式的平台就感觉意义不是很大,毕竟不是那种公众性质闹着玩的东西。因为在开放式平台,权限是个很麻烦的东西,毕竟如果任何人都可以上来改一下代码,有时候会很乱的。除非弄很多 branch 然后花很多时间 merge。。。

个人感觉:最佳的办法是,有人先做好底层框架,然后上层都用组件的方式来做,大家可以做一些小组件,或者更新一些小组件,这种开发模式可能更好一些。 关注中。只有一个问题。量化交易对于延迟的要求是苛刻的,就算是低频交易,相信对冲也是比较重要吧,对冲缺腿或者滑点了都是直接损失啊。只限制于单边恐怕太狭隘了点。 如果是做策略开发,重要的事情读三遍:重心放在回测引擎。

模拟成交价格靠下一秒quote还是bar?还是trade?那时的流动性跟得上?随机滑点设置要不要?最差价格成交要不要? 说实话,感觉啥也没写呀。。就封装了两个发单api。。
而且量化本来就是anti-open source的,最后你搞出来这些东西也就是自己玩玩,没什么实际意义。
还不如学学AQR写个pandas这种粗糙但是灵活的库。 个人感觉用python研究和构建策略还是很好的,至于交易方面,也许高频交易有scala等可以用,但是对实时性要求不高的很多地方,python交易平台是很好的选择。其实ib也有python的接口。

但是从定位上来讲,感觉能制作一个很好的接口就可以了。GUI界面的交易系统工作量太大,也许专门开一个开源项目来做? 作为新手我就提一个问题,华宝证券API是不是只支持Windows平台?那用Mac的人怎么办哟。 知识管理可以使用问答社区的形式,使用wecenter深度定制:
举例:
elasticsearch.cn

dockerone.io
推荐阅读
刘美娥94662
这个屌丝很懒,什么也没留下!
DevBox开发工具箱 | 专业的在线开发工具网站    京公网安备 11010802040832号  |  京ICP备19059560号-6
Copyright © 1998 - 2020 DevBox.CN. All Rights Reserved devBox.cn 开发工具箱 版权所有