主干开发中的代码审查实践（进阶教程）

主干开发为什么需要代码审查

在很多团队中，主干开发（Trunk-Based Development）已经成为标准流程。所有人直接向主干提交代码，分支生命周期极短，甚至没有长期分支。这种模式提升了集成频率，但也带来了风险——一旦有问题的代码合入，影响范围立刻扩大。这时候，代码审查就成了守住质量底线的关键一环。

不是所有改动都值得大动干戈

有些小修小补，比如改个拼写错误、调整日志输出格式，确实没必要走全套评审流程。但只要涉及核心逻辑、接口变更或性能调整，就必须有人看一眼。就像你在家做饭，随手热个剩菜不用叫家人试味，但做新菜总得有人尝一口吧。

如何高效做审查

审查不是挑刺大会。目标是发现问题，而不是让提交者难堪。一个常见的误区是等一大坨代码堆出来再审，结果没人愿意啃。建议拆成小块提交，每次不超过几百行。这样 reviewer 能快速理解上下文，反馈也更精准。

比如有段重构代码：

function calculatePrice(base, tax) {
  return base + (base * tax / 100);
}

// 改为支持折扣
function calculatePrice(base, tax, discount = 0) {
  const discounted = base - (base * discount / 100);
  return discounted + (discounted * tax / 100);
}

这种改动看着简单，但如果不说明 discount 的取值范围，默认为 0 是否合理，后续调用方可能误用。审查时顺手加个注释或者类型约束，能省下后期不少排查时间。

自动化工具要跟上节奏

人工审查不能替代机器检查。把 ESLint、Prettier、单元测试覆盖率这些配置好，CI 流程自动跑一遍，有问题直接标红。这样人可以专注看逻辑设计，而不是纠结括号对不对齐。

比如 Git 提交前执行钩子：

"scripts": {
  "prepare": "husky install",
  "lint": "eslint src/**/*.js",
  "test:ci": "jest --coverage"
},
"husky": {
  "hooks": {
    "pre-commit": "npm run lint && npm test"
  }
}

这类配置一旦落地，团队整体节奏会更稳。谁也不能绕开测试强行提交，也就减少了“我本地好好的”这类争执。

文化比流程更重要

有的团队把审查当审批关卡，非得某个 senior 点头才能过，结果 bottleneck 全集中在这儿。理想状态是多人参与，轮流 review，既分担压力，也促进知识流动。新人也能通过看别人代码快速上手，老手也能从不同视角获得启发。

关键是要建立一种习惯：提交即准备被看，被提意见不等于否定能力。就像写文章请朋友帮忙看看语病，改完道声谢就完事，别往心里去。