在软件团队协作中，主干开发（Trunk-Based Development）越来越常见。很多人以为只要把代码推到主分支就完事了，其实关键环节在代码审查——这一步没做好，再快的提交速度也救不了项目。
为什么主干开发更需要审查
主干开发强调所有人频繁向主分支提交小改动，而不是长期维护独立分支。这种模式下，代码合并速度快，但如果跳过审查，一个低级错误可能几分钟内就进入生产环境。比如上周某团队上线时服务突然崩溃，追查发现是一个成员直接推送了未测试的日志配置，导致整个集群磁盘被打满。
代码审查不是走形式，而是确保每次提交都符合规范、逻辑正确、不影响系统稳定性。尤其是在主干上，每一次提交都可能是“最后一环”。
怎么审才不拖慢节奏
有人担心审查会拖累效率，其实问题往往出在方式不对。理想的做法是：每次提交只改一个小功能或修复一个问题，让审查者能在5分钟内看完。比如你只是修改用户登录超时时间，那就别顺手重构旁边的方法。
提交信息也要写清楚。不要只写“修复问题”，而是说明“修复登录态保持时间过短问题，由30分钟调整为2小时”。这样别人一眼就知道改了啥，要不要重点看安全逻辑。
用工具辅助基本检查
很多低级错误其实不用人工盯。比如代码格式不统一、用了被禁用的函数、缺少单元测试等，都可以通过自动化工具拦截。下面是个简单的 GitHub Actions 配置示例：
<!-- .github/workflows/pr-check.yml -->
name: PR Check
on: [pull_request]
jobs:
lint:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Run linter
run: npm run lint
test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v3
- name: Run tests
run: npm test这类脚本可以在提交时自动运行，通不过就不能合并。省得审查者每次都重复说“缩进错了”“少写了测试”。
审查时重点关注什么
人工审查不用看每行语法，重点应该是：逻辑有没有漏洞？异常情况处理了吗？和现有设计是否冲突？比如看到一段删除用户数据的代码，就要问一句：删之前有没有二次确认？相关日志有没有保留？
另一个容易忽略的点是可读性。代码是写给人看的，机器只是顺便执行。如果一段代码让人看不懂，哪怕它现在能跑，未来维护成本也会很高。遇到这种情况，直接在评论里写：“这块逻辑有点绕，能不能加个注释或者拆成两个函数？”
别把审查当成挑刺
有些团队一提审查就紧张，觉得是在找毛病。其实好的审查氛围应该是互相帮忙。你可以试着把评论语气换成建议型，比如不说“你这里写错了”，而说“这里如果用 map 可能更清晰，你觉得呢？”
反过来，被审查的人也不用防御心太重。别人提意见不是针对你，而是为了代码更稳。就像做饭时家人尝了一口说“盐多了”，是为了菜更好吃，不是嫌弃你手艺。
主干开发节奏快，但不能牺牲质量。把代码审查当成日常习惯，就像出门前照镜子一样自然，项目才能既快又稳地往前走。