相对于本地化的投研平台，基于Web的投研平台具有先天的优势。
- 无需准备基础数据
- 标准化的编码工具
- 足量的计算资源。
- ……
这些都会提高策略研发过程的效率。
可惜的是，现有在线投研平台大都犯了一个错误（包括知名平台），那就是“工程师的设计”。
这要从对于投研人员的要求说起。
对于一名量化投研人员，有哪些基本要求呢？
- 懂金融知识
- 懂开发语言（Java、Python、Matlab等）
而现有的大多数投研人员，是金融背景，金融知识了解的比较多，在校期间用Matlab比较多，程序开发基础比较弱。但是，现有的SDK大多是程序研发人员制作的，因此，现有SDK的设计，更多是从功能出发的“工程师的设计”，而非从关注金融意义出发的设计。
什么是工程师的设计
举个简单的例子。
现有的SDK，基本都提供了标准的数据取用Function。在开发策略的时候，通过这些接口方法可以直接获取到标准化的数据。通常，得到的数据是一个二维矩阵的形式。如果是基于Python的平台，得到的数据可能是基于numpy包的Array，或者基于pandas包的DataFrame。
但是，这只是基础数据。在编写策略的时候，我们就需要对矩阵进行最基本的运算，如切片、转置、相加、相乘等。至于这些操作，SDK通常是没有提供标准化Function的，需要用户自己学习numpy、pandas或者其他包来实现。
所以，以现有的SDK来开发策略，代码逻辑基本是这样的：
当我们熟悉了这一流程之后，似乎整个过程行云流水，也符合功能的封装要求，没什么问题。
但是，问题就出在这里。如果你觉得单从策略的编码实现考虑，整体流程很顺畅，甚至没有太多的学习成本，说明你的开发基础很好，甚至本身就是技术研发背景。但是对于偏向金融背景的人员，虽然数据的处理对他们来说没有太大障碍，可他们的开发能力没这么好，不能很快把金融上的交易逻辑抽象为程序开发中的方法调用逻辑。
因此，现存SDK的问题就在于，将一个金融相关的过程，按照技术架构拆解，从而形成了Function的封装和调用逻辑。这样做的一个最直接的恶果就是，代码量翻倍增加。
优化的SDK设计
前面已经给出了基于技术封装的大体模式。虽然不够好，但确实是一种对于策略的基本封装模式，可以算是对SDK探索的第一步。那更好的SDK设计应该长什么样呢？
更好的设计，应该是在“技术封装”的基础之上，再进行“金融封装”。封装之后的SDK，应该包含以下几方面：
标准化的基本运算的标准化Func
例如：矩阵的切片、相加、相乘、转置、求逆矩阵等等。常用的金融计算的标准化Func
例如：求MA、IC、IR，计算移动均线上穿，股票筛选等等。
这样的设计，在大多数情况下，用户不再需要自己组织代码处理原始数据、计算基本指标、做逻辑判断等，可以用最简练的代码实现最核心的策略逻辑。其他的工作，交给SDK和背后的服务器搞定。
下面就来比较一下，优化前后，策略代码的变化是什么。
优化前的策略是这样的，这也是最简化的形式了：
import numpy as np
import pandas as pd
# 更多的包引用
import sdk
def data_init(**args): # 数据初始化方法
# 数据处理代码
return data
def buy(**args): # 买入方法
# 买入代码
def sell(**args): # 卖出方法
# 卖出代码
def handler(**args): # 处理程序，通常是回测时系统周期性的调用
data = data_init(init_args) # 初始化数据
if buy_condition: # 如果买入条件成立
buy(buy_args) # 调用买入方法
if sell_condition: # 如果卖出条件成立
sell(sell_args) # 调用卖出方法
但优化之后的SDK，最简单的形式应该是这样的（以MA5和MA10组成的双均线策略为例）：
import sdk
def handler(**args): # 处理程序，通常是回测时系统周期性的调用
zongshangsufuncs.market.cross_up( \\ # 上穿
funcs.market.ma(data.market.close, 5), \\ # 用收盘价计算MA5
funcs.market.ma(data.market.close, 10), \\ # 用收盘价计算MA10
funcs.trade.buy \\ # 如果上穿，执行买入
)
funcs.market.cross_up( \\ # 下穿
funcs.market.ma(data.market.close, 5), \\ # 用收盘价计算MA5
funcs.market.ma(data.market.close, 10), \\ # 用收盘价计算MA10
funcs.trade.sell \\ # 如果下穿，执行卖出
)
不同的视角
综上所述，这个平台并没有从实际使用者的角度去设计。
实际的用户，开发和金融能力都处在入门水平，面对复杂的SDK和冗长的策略代码，会望而却步。也因此，这样设计的最大坏处，其实是提高用户的学习成本，也就削弱了产品的运营属性。跟用户沟通之后做了统计，当简单策略的代码行数在5行以内时，有73.45%的用户愿意尝试一下；当行数增加到10行是，只有20.23%用户愿意尝试，并且这些用户多少有一些开发的背景。当代码行数超过20行的时候，就没人在愿意上手尝试了。
约稿、合著等，请联系[email protected]