3、代码审查方法论：静态代码分析工具、人工审查清单与常见违规模式
代码审查，说白了就是给交易算法做「体检」。我做了这么多年量化合规，见过太多因为代码里一个小bug导致几百万亏损的案例。今天咱们就聊聊怎么系统地做这件事。
3.1 静态代码分析工具：让机器先跑一遍
我个人习惯，任何代码提交之前，先让静态分析工具扫一遍。这就像去医院先做个血常规，能筛掉大部分明显问题。
3.1.1 SonarQube：量化团队的「守门员」
SonarQube 是我最常用的工具。它能检测代码异味、潜在bug、安全漏洞。对于交易算法，我特别关注这几个指标：
| 指标 | 说明 | 我设定的阈值 |
|---|---|---|
| 代码重复率 | 重复代码意味着维护噩梦 | < 5% |
| 圈复杂度 | 函数逻辑越复杂，越容易出bug | 每个函数 < 10 |
| 代码覆盖率 | 单元测试覆盖了多少逻辑 | > 80% |
| 安全热点 | 比如硬编码密钥、SQL注入风险 | 0 容忍 |
3.1.2 Pylint：Python 量化代码的「显微镜」
做量化交易，Python 是主流语言。Pylint 能检查出很多细节问题。我举个例子：
# 不推荐的写法
def calculate_pnl(trades):
pnl = 0
for t in trades:
pnl = pnl + t['price'] * t['qty']
return pnl
# Pylint 会提示：变量名太短，缺少类型注解
# 我建议改成这样：
def calculate_pnl(trades: list[dict]) -> float:
"""计算交易组合的盈亏"""
return sum(t['price'] * t['qty'] for t in trades)
嗯，这里要注意。Pylint 默认规则对量化代码来说有点「太严格」。我曾经遇到过团队因为 Pylint 报太多 warning，干脆把检查关掉了。这其实是个坑。我的做法是：
- 保留所有 error 级别检查
- warning 级别按团队共识裁剪
- convention 级别只保留命名规范
3.2 人工代码审查清单：机器看不到的地方
工具能查语法，但查不出业务逻辑错误。人工审查才是真正的「专家门诊」。我整理了一份清单，每次审查都按这个来：
3.2.1 交易逻辑审查
- 订单类型是否正确？ 限价单写成了市价单？我见过有人把 IOC 订单写成了 FOK，结果该成交的没成交。
- 价格精度处理？ 股票最小变动单位是 0.01，期货可能是 0.2。代码里有没有做四舍五入？
- 风控条件是否前置？ 检查资金是否充足、持仓是否超限，应该在发单之前做，而不是之后。
3.2.2 数据流审查
交易算法本质上是「数据进来，订单出去」。我审查时特别关注数据流的完整性：
- 行情数据有没有延迟？ 代码里有没有处理数据时间戳的逻辑？
- 异常数据怎么处理？ 比如某只股票突然停牌，价格变成 0，你的算法会崩溃吗？
- 日志记录是否完整？ 每个订单的触发原因、参数、结果，都要能追溯。
3.3 常见违规模式：这些坑我替你踩过了
做了这么多年审计，我发现违规模式其实就那么几种。我总结成了一张图，你一看就明白：
3.3.1 逻辑错误：最隐蔽的杀手
逻辑错误是最难发现的。我举个例子：
# 错误写法：止损和止盈条件写反了
if current_price <= stop_loss_price:
send_order('SELL') # 应该是止损卖出
elif current_price >= take_profit_price:
send_order('SELL') # 止盈也卖出？不对！
# 正确写法应该是：
if current_price <= stop_loss_price:
send_order('SELL', order_type='STOP_LOSS')
elif current_price >= take_profit_price:
send_order('SELL', order_type='TAKE_PROFIT')
你看，代码逻辑上没错，但业务含义完全不同。这就是为什么人工审查必不可少。
3.3.2 数据精度问题：积少成多的亏损
量化交易里，数据精度问题特别常见。我总结了几种典型情况：
- 浮点数比较： 永远不要用 == 比较浮点数。用 abs(a - b) < 1e-8
- 价格舍入： 不同交易所的最小价格变动单位不同。写代码时要参数化，不要硬编码。
- 时间精度： 毫秒和微秒的差别，在高频交易里就是天壤之别。
3.3.3 风控缺失：最不该犯的错
风控代码应该是交易算法的「安全带」。但我见过太多策略，风控逻辑写在最后，甚至没有。常见的缺失包括：
- 没有资金上限检查： 算法可能因为一个bug，把账户里所有钱都花出去买一只股票。
- 没有持仓限制： 单只股票持仓超过总资产的 20%，风险就太大了。
- 没有熔断机制： 市场剧烈波动时，算法应该暂停交易，而不是继续追涨杀跌。
嗯，这里我要强调一下。风控代码应该独立于策略代码运行。我见过有人把风控逻辑写在策略函数里，结果策略出bug，风控也跟着失效了。正确的做法是：风控作为一个独立的服务，在订单发出前做最后一道检查。
3.3.4 性能隐患：慢就是错
交易算法对延迟极其敏感。我审查代码时，会特别关注这些性能问题：
- 不要在循环里做数据库查询： 一次查询几十毫秒，循环100次就是几秒。行情早变了。
- 避免不必要的对象创建： Python 里频繁创建对象会导致 GC 暂停，在高频场景下是致命的。
- 使用合适的数据结构： 查找频繁用 dict，排序频繁用 list，不要搞混。
3.3.5 合规风险：红线不能碰
最后说说合规风险。这是最严重的，一旦触犯，可能面临监管处罚。常见的合规违规包括：
| 违规类型 | 具体表现 | 审查要点 |
|---|---|---|
| 自成交 | 同一策略的买单和卖单互相匹配 | 检查订单路由逻辑，是否有自成交预防 |
| 幌骗交易 | 挂单后立即撤单，制造虚假流动性 | 检查撤单率，超过阈值要报警 |
| 市场操纵 | 大额订单影响价格，然后反向交易 | 检查订单规模与市场深度比例 |
| 信息泄露 | 策略代码中硬编码了敏感信息 | 检查密钥、API地址是否加密存储 |
好了，代码审查方法论就讲到这里。记住，工具是辅助，人才是关键。静态分析工具能帮你筛掉 80% 的明显问题，但剩下的 20% 需要靠经验和责任心。下次审查代码时，不妨试试我今天讲的这套方法。
公众号:蓝海资料掘金营，微信deep3321