第三章：团队协作工具链
做市商系统不是一个人能搞定的。我见过太多团队，代码写得漂亮，但协作一塌糊涂。说白了，工具链就是团队的「交通规则」——没有它，早晚撞车。
3.1 Git版本控制工作流
做市商策略的迭代速度很快。今天加个信号，明天改个参数，后天回测发现逻辑有bug。如果没有好的分支策略，代码库很快就变成一锅粥。
我个人习惯用 Git Flow 的变体。为什么不是标准的 Git Flow？因为做市商业务有它的特殊性——线上策略不能停，回测和实盘要并行。
我们团队的分支策略：
master：只放线上运行的代码。每次合并必须经过 Code Review + 自动化测试。develop：日常开发的主分支。所有 feature 分支从这里拉出去。feature/*：新策略、新信号、新优化。命名如feature/volatility-breakout。hotfix/*：线上出问题时的紧急修复。直接从 master 拉，修完合并回 master 和 develop。release/*：版本发布前的冻结分支。只修 bug，不加新功能。
举个例子。有一次我们上线了一个新的做市策略，结果发现某个交易所的行情数据有延迟。我直接从 master 拉了 hotfix/exchange-latency，修完合并回去，整个过程不到20分钟。如果当时没有清晰的分支策略，光协调代码冲突就得花半天。
3.2 Code Review最佳实践
Code Review 不是走过场。我见过有些团队，Review 就是「LGTM」三个字母。嗯，这种 Review 还不如不做。
做市商代码有个特点——数值精度和边界条件极其敏感。一个浮点数精度问题，可能导致几万美金的损失。所以我们的 Code Review 有硬性要求：
| 检查项 | 说明 | 严重等级 |
|---|---|---|
| 数值精度 | 是否使用 Decimal 而非 Float | P0（必须修复） |
| 边界条件 | 订单簿为空、价格为0、数量为负 | P0 |
| 日志输出 | 关键路径是否有日志，日志级别是否合理 | P1 |
| 异常处理 | 网络超时、交易所返回错误码 | P0 |
| 代码风格 | 是否符合团队规范 | P2 |
我曾经因为一个 float 精度问题，导致做市策略在某个价格点上反复报单撤单。Review 的时候没人发现，上线后亏了大概 2000 USDT。从那以后，我们规定所有价格和数量必须用 Decimal，Review 时必须逐行检查。
我的 Review 习惯：
- 每次 Review 不超过 200 行代码。超过的，让作者拆成多个 PR。
- 先看测试，再看实现。没有测试的代码，直接打回。
- 评论要具体。不说「这里不好」，而是说「这里如果交易所返回空列表，会触发 NullPointerException」。
3.3 Jira/Confluence任务管理
做市商团队的任务管理，核心就两个字——追踪。你今天改了哪个参数？为什么改？谁批准的？这些信息必须可追溯。
我们用 Jira 管理任务，Confluence 管理文档。结构大概是这样的：
Jira 项目结构：
- Epic：大的功能模块，比如「做市策略V2」、「风控系统重构」。
- Story：具体的用户故事，比如「作为做市商，我希望在订单簿深度不足时自动调整报价」。
- Task：开发任务，比如「实现订单簿深度监控模块」。
- Bug：线上问题，比如「某个币对在特定时间点报单失败」。
- Sub-task：更细粒度的拆分，比如「编写单元测试」、「编写集成测试」。
Confluence 那边，我们维护了几类关键文档：
- 策略设计文档：每个策略的原理、参数、风险点。
- 运维手册：如何部署、如何监控、常见问题处理。
- 复盘报告：每次线上事故后的根因分析和改进措施。
你想想看，如果没有这些文档，新人来了怎么上手？我记得有一次团队来了个新同事，我直接把 Confluence 链接发给他，他花了两天看完所有文档，第三天就能独立处理线上问题了。这就是文档的力量。
注意：Jira 和 Confluence 最怕「只建不用」。我见过有些团队，Jira 上堆了几百个没人管的 ticket，Confluence 里全是过期的文档。定期清理和归档很重要。我们每两周做一次 ticket 梳理，每月做一次文档审计。
3.4 知识体系总览
下面这张图，是我对团队协作工具链的整体理解。你可以把它当作一个「导航图」：
说白了，工具链的核心目标就三个词：可追溯、可复现、可协作。每个改动都有记录，每个决策都有依据，每个人都能上手。做到这三点，团队协作就不会出大问题。
最后说一句：工具是死的，人是活的。再好的工具链，如果团队不遵守，也是白搭。我建议你从一个小项目开始，逐步推行这些规范。别想着一步到位，那只会让大家反感。