104周转行Quant | W04 - C++的OOP魔法(下)

type

status

date

slug

summary

🏦SigmaX的日常

承接上周的故事，很不幸，SigmaX的量化团队在经历了A股的大回撤以及几个重要投资策略的失败之后，决定进行一次大规模的团队重组和优化。不过万幸的是，富婆给的投资还剩一半，黑犬痛定思痛，裁掉了人美心坏的HRBP，找了几个在量化行业有经验的前辈的咨询公司帮忙进行组织优化。

前辈们经过调研，发现SigmaX的量化团队存在几个问题：

团队成员角色不清晰，职责重叠，导致效率低下

团队成员之间缺乏有效的沟通和协作，信息孤岛严重

团队缺乏明确的目标和绩效评估

除了量化三大金刚的核心岗位（QR、QD、Trader）之外，缺乏必要的支持岗位（如数据工程师、风险管理、投资组合管理等）

基于这些发现，前辈A建议：“重新设计员工之间的协作模式，捋清公司业务架构，并且对公司不同的业务要有实时的监控和感知”。

黑犬点点头，准备还是用自己最擅长的代码来进行业务的重新设计。想了半天，不如使用设计模式来对原有的OOP代码进行优化吧:

岗位角色：硬编码每一个不同的岗位 -> 使用工厂模式来创建不同类型的员工对象

团队协作：成员角色之间没有统一的协作模式 -> 使用观察者模式来实现成员之间的事件通知和协作：创建一个团队事件系统

业务管理：每个岗位的职责和工作内容不清晰 -> 使用策略模式来定义每个岗位的工作职责和任务

这样一来，刚刚前辈提到的几个问题都能迎刃而解，并且代码的设计也会更加清晰和易于维护，重要的是也符合OOP程序代码设计的几大原则：

单一职责原则（SRP）

开闭原则（OCP）

依赖倒置原则（DIP）

这时前辈B站了出来：“还不够，要做好风控、投资组合管理、合规，数据方面也得有专人去管吧，数据工程、数据科学家或者SRE至少得有一个，另外订单执行、盈亏的实时监控和告警，多少也该有吧…”

啊对对对，黑犬用小本本记下了所有前辈给的建议，并且对原有代码做了整体的改进：

在以上核心代码之外，黑犬还充分使用了智能指针、RAII等现代C++特性来保证代码的安全性和性能，在原有的团队架构增加并完善7种专业角色: QR、QD、Trader、Risk Manager、Portfolio Manager、Data Scientist、Compliance Officer，并且定下了公司的日常工作流：晨会→策略讨论→代码审查→风险评估→绩效回顾,同时也增加了预算管理、绩效、投资组合管理、监控系统的相关工作逻辑。

最终，黑犬尝试重新招募了一批有经验的量化团队成员，并且使用新设计的代码系统来管理和协作，这是在SigmaX量化团队的一天：

好不容易，SigmaX再次回归了正轨，黑犬也松了一口气。再给两位前辈送了两箱茅台之后，黑犬回到老板办公室，扔掉了原木大桌和皮椅，换上了简约风的办公桌和人体工学椅，把书架上的手办也给扔了，换成了营销和商业管理书籍，最后把黑丝小秘书也给辞退了，换成了一个十年金融行业经验的财务助理。

创业不是过家家，量化更不是玩票，专业的人做专业的事，才能走得更远。

📒补充说明

本周的SigmaX的故事中，黑犬主要给大家介绍了三个基础的设计模式：单例模式、观察者模式和策略模式，这些设计模式在实际的C++项目中都有广泛的应用，尤其是在复杂系统的设计中，能够帮助我们更好地组织代码结构，提高代码的可维护性和扩展性。

当你在使用OOP进行项目设计时，设计模式是绕不开的一个话题，实际上常见的设计模式有20余种，需要你结合实际的业务场景去灵活运用、去悟。三大原则（SRP、OCP、DIP）也是每一个OOP程序员必须要牢记的设计准则，这几个准则能够帮助我们避免代码的过度耦合和复杂性，提高代码的质量。市面上已经有很多关于设计模式的书籍和资源，大家选择自己喜欢的进行学习即可，重点是找到自己善于理解的场景去实践它，这玩意背不下来的，希望SigmaX的故事能给你一个有趣的角度去理解它们。

本周代码已经上传到Github仓库🔗：https://github.com/shuheng-mo/qd-study-plan-104wk.git

下周预告：W04 - C++的OOP高级用法（上）

👋各位下周五见，我是在做梦成立自己量化公司的黑犬momo酱。