证券量化研究 软件开发-论文写作与量化研究

为什么证券行业的软件研发水平远低于互联网科技公司？其实，不仅是传统证券金融业IT，其他绝大部分传统垂直行业IT，就技术前沿性和专业性而言都是距离科技公司颇远的。不管愿不愿意接受，一个事实是，顶级名校的计算机系毕业生，职业首选肯定是去投奔互联网巨头的研究院、跨国IT公司、创业公司独角兽。不信？调查一下自己所在金融机构的IT部门看看今年新招毕业生的学校和学历分布，例如看看有没有来自清华北大交大神马的。在米帝那里，华尔街的投行如高盛、摩根斯坦利、美林等等，因为有品牌效应和丰厚的薪酬，还能吸引到一些不错的IT人才；高盛、摩根都拥有上万的IT人员，其研发的能力也不容小觑。可是，这些IT组织在IT界的影响力、对业界的技术贡献、自身的总体水平，和Google、Amazon比还是差很远的。

看到这里，作为证券业IT人士的你忍不住跳起来了，你可能会提出两点来驳斥这个“谬论”。 首先，你会说“唯学历”观是错误的 – 这个无异议哈，高分低能的多了去了。燃鹅，我们在这里只是陈述一个“客观指标”，例如一些大券商都喜欢标榜自己的员工平均学历神马的，有些甚至要在微信公众号各种秀员工们的“颜值”哈，金融业从外面看是个高大上行业，招募到的年轻人都是高颜值的顶级名校毕业生，非985、211学校的进不来，行业风气如此…但金融IT显然是例外（很不中听），因为有浓厚技术爱好和极强能力的计算机系毕业生首选肯定都跑某软亚洲研究院、直接肉身翻墙去米帝、或者起码投奔国内某互联网大厂或某独角兽去了。

话又说回来，其实，一个高度偏科没考上好学校的极客型人才，例如只有高中大专学历，不“唯学历观”的你会招聘他吗？就算你会，你也得起码经历两次“破格”申请、三度流程、四次人力资源部驳回，最后碰到一位开明的领导，才能“破格”录用他（别问我怎么知道的(◐‿◑)）。

说到拿金融机构IT的水平和互联网巨头比不公平，那么我们不拿Google来说事。我们说说Netflix（网飞）肿么样？2016年，Netflix的营收是88.3亿美元，高盛是377.1亿美元。它们分别从营收中拿出了多少投入技术研发没去仔细研究，但以体量来粗略的看，后者的投入再怎么着不可能比前者少。Netflix开始时就一网上出租录影带和DVD的，后来变身视频娱乐服务商和内容提供商，但过去几年成为Micro Services、DevOps的先驱，提出了Chaos Engineering、Intuitive Engineering的理念，也开源了很多的技术，在互联网甚至传统金融机构都有这些技术的追随者和应用者（Netflix的一些具有“反脆弱”性的技术其实最应该在证券业借鉴），影响了许许多多的工程师。

另一方面，我们中又有谁受过高盛摩根们的高大上牛掰交易系统开发大拿的技术理念影响或者用过他们什么开源技术？金融机构向来标榜系统运维在高可靠性、稳定性、健壮性方面的牛，可是SRE（Site Reliability Engineering）是Google提出的，云上分分秒秒成千上万次系统升级的能力是亚马逊率先具备的，我们就不扯NoSQL、Deep Learning、Containerization等等这些工具、技术、理念基本来自哪里了。这里想说的是，证券金融业数字化程度相比其他行业算非常高、业务场景也非常复杂、非功能性系统要求（例如高并发、低延迟、高可用等等）也超级挑战，有钱的投行IT投入也足够大，理论上能诞生可以普惠社会的技术理论和工具，可是最终并没有利用这些条件向技术界反馈反哺、贡献出有价值的技术成果。

证券业其实是有孕育牛掰技术的应用场景和环境的，对交易应用来说，分布式架构15年前就不是新鲜事物，内存数据库的应用是家常便饭，交易消息中间件过去二十年被重写过无数次，高频极速交易在利润的驱使下对技术的运用可以说无所不用其极；甚至在一些科技领域华尔街可以说曾经走在最前沿，例如80年代末，多核（multi-core）CPU技术都还不知道在Intel哪个实验室里，多个CPU（multi-processor）多路并行运算（Parallel Computing）是超级高大上昂贵的技术，代表了高性能运算（HPC）领域的最高成就，华尔街投行们在利润的驱使下绝对是是率先的运用者，程序猿们甚至已经研究和使用能驾驭多路CPU的编程语言Linda编写交易系统– 起码十多年后基于同样理论的技术（JavaSpaces）和商用平台（GigaSpaces）才出现。 可是像CAP Theorem、Reactive Manifesto、Micro Services、DevOps、Big Data等等这些技术理论与理念，却没有在这个行业诞生，为啥？

原因不外以下几条。

首先，是证券业IT对技术的态度。从证券IT人嘴里听过不止N次语重心长的论调“技术不重要，不要过分强调”，意思是说，行业IT的主要目标是开发、支持业务应用系统，不管用什么技术，只要可靠、稳妥、“成熟”，能把应用系统功能按业务部门要求做出来就行了。所以，管它用J2EE还是.Net还是其他什么鬼，按时交货、上线不出问题，是最高目标。事实上，在强监管类型的行业里，一些软件公司只要紧跟监管政策法规，不管用什么古老技术，只要监管机构提出一个新要求就做一个新模块、市场批准一项新业务就做一类新功能，然后卖给无任何开发能力的行业机构们坐地收钱，也就活的很好。所以是不太需要什么技术追求的。

其次，是金融行业IT总体缺乏开放的习惯与文化，没有行业生态的概念和“协作竞争”（co-petition）的意识。在互联网里，开放平台、API经济都是老生常谈，在金融业里也许因为行业的特殊性，导致开放非常困难。例如摩根斯坦利（Morgan Stanley）的IT，起码在90年代初（Google、Amazon还不知道在哪个角落的时候），就已经拥有强大的平台研发团队，自己研发跨Windows、UNIX（N个流派）的UI框架与开发环境MSToolkit，充分运用了很多面向对象设计的最佳实践；为了加快复杂程序的编译速度甚至实现了在SGI（当时最高性能的UNIX Workstation）上的cross-compilation（跨操作系统的二进制代码编译）。当互联网还处于婴儿期、Netscape（网景）还是明日之星的岁月里，Morgan Stanley的Client Connectivity团队已经向Netscape不谋而合的提出Web服务器（当时还是新生事物）的插件（plugin）理念并率先在FastTrack Server（比Apache还早的Web服务器）上实现。

可是今天这些技术成果都去了哪里？真是应了那句话，“神马都是浮云”了。不开放的技术没有生命力，既不造福行业，也无法自利利他，无论曾经如何的前沿，最终也被一波波新兴的开源技术替代、拍死在沙滩上。其实拿着“监管行业特殊性”、“信息安全”这几根鸡毛，是否就可以当作令箭来实行自我封闭？恐怕未必，开放并不等于“不保密”、“信息不安全”，其实更多是一种文化、习惯、思维问题。一些技术例如是否可以在行业范围内开放？是否增加透明度和更加安全？co-petition这种“自利利他”的理念，在包括华尔街在内的传统行业，始终缺乏深刻认识。

当然，开放说的容易做起来难。例如互联网曾经的先锋、现在的先烈Yahoo，虽然是一家互联网公司，却是一个“放弃了不该放弃的，坚持了不该坚持的”悲催例子。除了放弃收购Facebook的著名案例，在它的“中晚期”，却死守一些古老的封闭的内部自研发技术，不愿意拥抱互联网上开源的技术，整个技术文化都开始更加像一家“传统IT企业”。

最后，是典型垂直行业通常在IT方面比较“短视” – 和促进业务没有直接肉眼可见关系的投入，都是拒绝的。例如假设在一家证券公司里证券量化研究 软件开发，自己研发一套消息中间件 - IT团队如果真想干这事，只有在不影响业务型项目的进度的前提下、发挥极其巨大的“主观能动性”、自发自觉加班加点或者躲在家里作为业余兴趣搞，才有机会做个原型，而且因为没有立项，所以把技术成果“变现”的机会甚微。大部分的大型金融机构也不见得会理解为什么需要自己投入这么基础的技术研发。一年赚个几百亿美元的、可以算的上金融界Google体量的高盛摩根们，在投入基础技术研发方面尚且有挑战 – 随时面临内部业务部门成本分摊扯皮问题，毕竟不是自定位为“技术公司”，负责决策的高管们（通常不是程序猿出身）也无法弄明白一套消息中间件的奥妙，要说明白为什么不能用RabbitMQ、ActiveMQ改造一套，或者为什么不合适直接采用Tibco Rendezvous之类，而非得自己研发一个，可以算“秀才遇着兵，有理说不清”，更不要说IT人口舌通常都是笨拙的（现在能把一个技术问题举重若轻的给业务人员、客户、领导说明白，是IT人最最最重要的素质 – 几乎没有之一）。有些华尔街机构也许已经意识到“技术基因”的问题，近年来开始把自己称之为“科技公司” – 光说没用，得“移风易俗”注入科技血液，但无论如何也姑且算是迈出了观念上的一步吧。

上述对IT的态度、观念与文化，可以说不仅在金融业、在其他非技术行业都是类似的。这种环境下，导致这样一些连锁反应。

IT缺乏专业性。典型的开发工作是这样的：收集需求 ->分析需求->整理需求 ->开发（更多是协调外包商开发） ->测试（人肉黑盒子测试）->部署（人肉部署）。因为不把自己定位成一个专业软件组织，所以这里每一个环节通常都是比较随意、业余的，例如“需求分析”当然也不会用到什么OOAD（面向对象分析方法）、不会通过UML从多维度呈现需求的视角、不会有规范的用例场景（Use Case）管理；例如“开发”环节自然也不会采用领域建模（Domain Modeling）来对业务逻辑进行规范构建、也不会用专业工具作持续集成与代码测试覆盖率自检（code coverage）、也没有严谨的技术架构论证；例如“测试”环节也没有什么TDD、BDD的方法论或者QE白盒测试；例如“非功能性”的系统指标往往只是上线出现问题才救火补漏…

以为能够快速实现业务逻辑、迫不及待完成任务，却因为软件工程的专业性认识的欠缺，导致开发出来的软件系统非常的不专业。以纯粹完成业务功能为导向的IT组织，不管是开发商还是金融机构，都有自我定位为“业务部门的搬砖工”的倾向，一切围绕功能需求，机械堆砌代码，技术方面正如欧阳修《卖油翁》里的名句：“唯手熟尔”。

缺乏专业性的IT组织，通常也没有工程师文化，所以是无法吸引到优秀工程师的。没有优秀的工程师带动与引领证券量化研究 软件开发，那么团队里就缺乏跨行业的、从其他地方来的新思维、新技术、新理念的碰撞，思想与文化处于一个封闭的无流动性的小池塘中，技术新人就跟着“唯手熟尔”的老司机干，遵循着他自己“土法炼钢”摸索出来的一些“实践”，一代代“薪火相传”，惯性的思维、固化的观念、已经忘记本源的流程，就这么延续下去…

如果能够这么稳定的延续下去，对于一些同志来说当然也是一个稳定职业。只可惜，靠“唯手熟尔”谋生的日子即将一去不复返了，因为这种工作正是AI的拿手好戏 – 熟手技工们，恭喜你，套用网上常用的“虽然…但是…”句型造句：“虽然你技术很烂，但是你这么个被动搬砖工对金融业务核心也不理解啊”，很快你将成为《人类简史》作者尤瓦尔·赫拉利所谓的“无用阶级”一员。

这里有一个恶性循环：一个没有工程师文化的组织，吸引不到一流的技术人才，所以就不会有很牛掰的技术，就不会吸引有技术追求的毕业生，就没有技术文化传统与传承，就不会创新，技术债就总是还不清也无暇学习运用最新科技成果，所以就无法吸引到科技人才，所以就不会有工程师文化、所以就吸引不到技术人才……

新技术，都是为了更好的解决一些问题而出现的，例如我们常说“语言是思维的外壳” – 一门新的计算机语言往往用来思考、建模某个领域的问题从而解决它比用其他语言更适合（所以它才会诞生），而容器化技术则对于我们建立DevOps的实践以更好的运维金融业务系统非常有帮助。畏惧、抗拒新技术的态度无法抵御技术迭代更新越来越快的时代车轮碾压。技术与金融业务的结合，关键在于技术能用得其所。一支金融科技研发团队，应该是由一群跨界、复合型人才组成的 – 看到业务创新需求的时候，能想到在自己与时俱进的技术武器库里找到最合适的工具来实现它；看到新技术（例如区块链）出现的时候，能努力联想一些新的业务可能。为什么在做好金融业务功能的同时，就不能用上最前沿最好玩的技术呢？这两者有冲突吗？

（此处是一个突兀的转折）我们正在建设这么一个跨界团队（不错，哼哼(⊙v⊙)，您现在看到的其实是一篇招聘软文）。

警告：前方有广告出没٩(˃̶͈̀௰˂̶͈́)و。

---------我是火眼晶晶的分割线---------

在招岗位

Quant工程师、大数据平台工程师、机器学习研发工程师、分布式系统工程师、移动端工程师、泛前端工程师

基本要求

拥有正确的技术思维、观念和方法论比掌握层出不穷的具体技术更根本更重要;此外，综合技术素质也同样关键。所以我们希望从面谈交流中了解：

（1）基本理论。您对数据结构与算法、计算机语言基本原理、面向对象建模、分布式架构基本要素有深刻理解；

（2）方法论。您是一个quicklearner-无论是学习一门新的语言、一个陌生的前端框架还是一种新的存储技术，您都能在较短时间内正确掌握，并且具备成体系的学习套路与方法；

（3）交流沟通能力。我们鼓励团队成员大量阅读（不一定只是技术书籍，谁说历史哲学不能触类旁通），鼓励写作发表技术文章以及在各大峰会演讲。最起码您得逻辑的归纳总结和描述一个问题，并逻辑的描述它的解决方案；

（4）其他加分项。例如您写过一些技术的博客文章、钻研过一些还没机会运用的技能…具体不限，我们愿闻其详；

（5）流畅阅读英文技术文档的能力必须具备，因为我们期望您能开拓自己的视野、并通过分享来开拓团队伙伴们的视野（所有成员都为彼此做同样的分享）。

金融领域经验和技术经验在我们这里不是唯一最重要的，技术热情、知识面、逻辑分析能力、好奇心、总体潜力与悟性更加关键。技术岗位也不是固定的，您可能先以个人最熟悉的技术作为切入点，但是您有相当高的机会被安排去尝试全新的领域。

开卷有益 – 以下是具体岗位面谈交流中我们打算讨论的部分内容。

1、机器学习类职位面谈内容

请就自然语言处理、机器学习、神经网络、知识图谱、Caffe和Tensorflow 等深度学习框架、neo4j等图存储数据库… 以及其他任何相关技术聊一下，我们愿闻其详。

2、大数据平台相关岗位面谈内容

请分享你对分布式文件系统、关系型数据库、Java/Scala/Shell或者其他任何一种语言、Hadoop/Storm/Spark/Flink/ElasticSearch/Kafka/ELK相关技术中的一些有趣见解。

3、交易应用开发类岗位面谈内容

对于这个岗位我们想交流一下Java/Go等开发语言，以及面对对象设计模式、常用的并发编程模型。如果在过往项目中使用过docker，有过证券行业软件开发经历，拥有证券／基金从业资格等等更棒了。

4、消息中间件开发岗位面谈内容

对于这类岗位我们想聊聊计算机语言– Golang、Java、C++都行，还有常用算法和数据结构，网络编程、多线程编程技术及RPC框架也有必要交流一下，其他例如Cloud-native patterns和分布式架构一些最佳实践我们愿闻其详；如果能解释清楚Paxos/Raft一致性算法、或者清晰阐述Docker/Swarm/Kubernetes容器相关技术的原理，当然更好了。

5、iOS/Android/HTML5泛前端类岗位面谈内容

无论开发移动类应用还是桌面的混合（Hybrid）应用，客户端技术有一定的相似性和共通性，除了Objective-C、Java、JavaScript这些不同语言的技巧掌握外，对业务应用逻辑如何规范、有效的“建模”以保障前端的可扩展性，也非常重要， 请讲讲你的见解；此外客户端如何配合解决“互联网最后一公里”、向用户提供优质用户体验有什么心得体验，请充分讨论分享。ES6/7、Kotlin、Swift这些语言，有各种异同，如果了解过比较过，请深入介绍。

6、Quant金融算法开发岗位要求

在这个岗位上，您将有机会向华尔街同行深入学习固定收益类金融产品的纵深专业知识，了解算法模型，深入到量化交易与风控的核心，并对多资产交易系统的生态有完整认识，获得在固收领域相对稀缺的专业技能，吸取大量专业知识，在金融业务与技术两方面大开眼界

职位要求。对于这个岗位，我们不要求直接相关的金融专业背景和经验，但是我们要求以下必备条件：

（1）非常过硬的基础数学功底 - 请出示您在本科高等数学的分数，并展现个人数学知识

（2）能够开发高效、可靠、算法合理的计算类程序并乐在其中。对计算机科学里“数据结构与算法”等学科，必须牢固掌握，熟悉各种常用算法并合理运用

（3）对C++11、Golang等语言熟练掌握，有Scientific Computing相关研究经验或学习背景最佳，能编程处理高精度浮点运算。对计算机语言原理（Programming Language Theory）必须有基本理解，对编写“thread-safe”的程序有起码了解

（4）英文6级或以上，阅读能力强，并能以英文作为日常邮件书面语言（不要求听、讲）

（5）211、985大学硕士或以上，理工科博士欢迎

（6）您必须是一个quick learner - 我们预期这个岗位被各种您陌生的金融知识、技术知识轰炸，应聘者需自我证明在较短的时间内能用高效、成体系的方法学习掌握陌生知识

（7）其他有用的经验，包括：熟练使用Excel作复杂计算、开发过Windows应用等等。

投递邮箱：hr@finogeeks.com