26、做市商团队协作:代码规范(Google Style),Git工作流(GitFlow),Code Review流程
做市商系统不是一个人能搞定的。我见过太多团队,代码写得飞起,结果上线第一天就崩了。为什么?因为大家各写各的,没人管规范。今天咱们聊聊团队协作的三板斧:代码规范、Git工作流、Code Review。
一、代码规范:Google Style 落地实践
代码规范这事儿,说白了就是让团队写出来的代码像一个人写的。我个人习惯用 Google Style,原因很简单——它经过了 Google 内部海量项目的验证,坑少。
1.1 Python 规范要点
做市商系统里,Python 主要负责策略回测、数据分析和监控脚本。我建议你直接用 yapf 或 black 做自动格式化,别手动调缩进。
核心规则:
- 缩进:4个空格,别用 Tab。我在项目中遇到过有人混用 Tab 和空格,结果 CI 直接挂了
- 行宽:80字符。超过就换行,用反斜杠或括号包裹
- 命名:变量用
snake_case,类用CapWords,常量全大写 - 导入:标准库 → 第三方库 → 本地库,每组之间空一行
# 好的写法
import os
import sys
import numpy as np
import pandas as pd
from my_project.order_manager import OrderManager
from my_project.risk_control import RiskController
MAX_ORDER_SIZE = 1000 # 常量全大写
class MarketMakerEngine:
"""做市商引擎主类"""
def __init__(self, symbol: str, base_qty: float):
self.symbol = symbol
self.base_qty = base_qty
self._order_manager = OrderManager()
1.2 C++ 规范要点
C++ 负责底层交易引擎和行情处理,性能敏感。Google C++ Style 对这部分有严格规定。
我的经验:做市商系统的核心引擎,我建议用 clang-tidy 做静态检查。曾经有个同事在订单路由模块里用了 std::shared_ptr 循环引用,导致内存泄漏,查了两天才找到。后来加了智能指针检查,再没出过类似问题。
// 好的写法
#include <string>
#include <vector>
#include "absl/strings/str_format.h"
#include "glog/logging.h"
class OrderBook {
public:
explicit OrderBook(const std::string& symbol);
// 成员变量用下划线结尾
void UpdateBid(double price, int64_t qty);
private:
std::string symbol_;
std::vector<Order> bids_;
};
二、Git工作流:GitFlow 实战
做市商系统迭代快,bug 修复要分钟级响应。GitFlow 虽然老,但适合这种需要严格版本管理的场景。
注意:别在 master 分支上直接改代码。我曾经见过一个团队,为了省事直接在 master 上修 bug,结果回滚时把别人的代码也带回去了,整个交易系统停了半小时。
2.1 分支结构
我建议你们用这套分支模型:
2.2 日常操作流程
- 开发新功能:从
develop拉feature/xxx分支 - 修 bug:从
master拉hotfix/xxx分支 - 发布:从
develop合并到master,打 tag - 回滚:用
git revert,别用git reset
小技巧:提交信息用 conventional commits 格式。比如 feat: 添加订单簿深度限制 或 fix: 修复价格精度溢出。这样生成 changelog 时直接就能用。
三、Code Review 流程
Code Review 不是走过场。我见过最离谱的团队,review 就是点个 approve,代码里藏着死循环都没发现。做市商系统里,一个 bug 可能亏几百万,所以 review 必须认真。
3.1 谁来做 Reviewer
| 角色 | 职责 | 必须检查的内容 |
|---|---|---|
| 技术负责人 | 架构合理性 | 模块划分、接口设计、性能影响 |
| 同级工程师 | 代码质量 | 命名、逻辑、边界条件 |
| QA 工程师 | 可测试性 | 单元测试覆盖、异常处理 |
3.2 Review 检查清单
我建议你们用这个清单,每次 review 逐条过:
- 功能正确性:代码逻辑是否满足需求?边界条件处理了吗?
- 性能:有没有不必要的循环?数据库查询次数合理吗?
- 安全性:输入校验了吗?有没有 SQL 注入风险?
- 可维护性:代码容易理解吗?注释够不够?
- 测试覆盖:关键路径有单元测试吗?异常场景测了吗?
避坑指南:我曾经 review 过一个订单路由模块,代码看起来没问题,但没注意到它用了 sleep() 来等待行情更新。结果上线后,行情延迟 500ms,做市策略全废了。所以 review 时一定要关注 非功能性需求。
3.3 Review 流程
- 提交 PR:描述清楚改了啥、为啥改、怎么测的
- 分配 Reviewer:至少 2 个人,一个技术负责人,一个同级
- Review 过程:逐行看代码,提 comment,讨论修改
- 修改后重新 review:别直接 approve,确认修改没问题
- 合并:用 squash merge,保持历史干净
四、工具链推荐
光说理论没用,得配上工具。我给你们列一下我们团队用的:
| 工具 | 用途 | 配置方式 |
|---|---|---|
| pre-commit | 提交前自动检查 | 配置 .pre-commit-config.yaml |
| clang-format | C++ 代码格式化 | 配置 .clang-format |
| pylint | Python 静态检查 | 配置 .pylintrc |
| GitHub Actions | CI/CD 自动化 | 配置 .github/workflows/*.yml |
总结一下:代码规范是底线,GitFlow 是流程,Code Review 是质量保障。这三样东西,缺一个,做市商系统就等着出事故。别嫌麻烦,前期规范一点,后期少熬夜。