26、做市商团队协作:代码规范(Google Style),Git工作流(GitFlow),Code Review流程

做市商系统不是一个人能搞定的。我见过太多团队,代码写得飞起,结果上线第一天就崩了。为什么?因为大家各写各的,没人管规范。今天咱们聊聊团队协作的三板斧:代码规范、Git工作流、Code Review。

一、代码规范:Google Style 落地实践

代码规范这事儿,说白了就是让团队写出来的代码像一个人写的。我个人习惯用 Google Style,原因很简单——它经过了 Google 内部海量项目的验证,坑少。

1.1 Python 规范要点

做市商系统里,Python 主要负责策略回测、数据分析和监控脚本。我建议你直接用 yapfblack 做自动格式化,别手动调缩进。

核心规则:

  • 缩进: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 分支结构

我建议你们用这套分支模型:

master develop feature/* hotfix/* GitFlow 分支模型:master → develop → feature/hotfix

2.2 日常操作流程

  1. 开发新功能:从 developfeature/xxx 分支
  2. 修 bug:从 masterhotfix/xxx 分支
  3. 发布:从 develop 合并到 master,打 tag
  4. 回滚:用 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 流程

  1. 提交 PR:描述清楚改了啥、为啥改、怎么测的
  2. 分配 Reviewer:至少 2 个人,一个技术负责人,一个同级
  3. Review 过程:逐行看代码,提 comment,讨论修改
  4. 修改后重新 review:别直接 approve,确认修改没问题
  5. 合并:用 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 是质量保障。这三样东西,缺一个,做市商系统就等着出事故。别嫌麻烦,前期规范一点,后期少熬夜。

交易系统化学习资料 微信Strategy888888