1. 代码审查到底在审什么：先想清楚这件事值不值得做
代码审查（Code Review）这词儿，但凡是写代码的，基本都听过。有些人觉得它是形式主义，走个过场点个赞就完事；有些人觉得它是团队里最有价值的一环，每次提 MR 都盼着有人能帮自己看出点问题。我做了这么多年开发，从被审到审别人，从几个人小团队到几十人的研发部门，对这个事的看法经历过好几轮变化。
先说结论：代码审查不是“检查代码有没有写错”，而是“用最低的成本，防止错误和误解在代码库里积累”。它解决的核心问题是——代码不是写给自己看的，是写给半年后的自己和整个团队看的。你写代码当时觉得天经地义的逻辑，别人看起来可能一头雾水；你为了赶进度临时绕过去的一个 edge case，可能就是线上事故的种子。
所以这篇博文不是给你讲“要拥抱 Code Review”这种正确的废话，而是把我实操中总结出来的审查策略、节奏把控、评论话术、工具搭配这些经验全部拆开讲清楚。不管你是刚入职的新人、带项目的 tech lead，还是想在公司推这套流程的负责人，都能在里面找到能直接用的东西。
很多人对代码审查的第一反应是“浪费时间”——改三行代码，等审查等了一天。这个痛点特别真实。但如果你把审查看作“写代码的一部分”，而不是“写完代码之后的额外负担”，时间和流程问题是完全可以解决的。关键在于：审查的节奏、粒度、方式，都应该是团队磨合出来的结果，而不是照搬某个大厂的制度。网上那些天天吹“谷歌强制所有代码必须过 review”的帖子，对中小团队来说参考意义真的有限，我们团队的实际做法是“分级审查”，后面我会详细讲。
另外，最近“open code review”这个概念在圈子里讨论挺热。我的理解是，它不只是“开放代码，让大家都能审”，更是指审查这件事本身要透明、要可讨论、要让每个人都敢提意见。代码审查如果用成了“领导挑刺大会”，那代码质量一定好不了。后面我会用一整节专门讲怎么把审查变成团队能力和信任的放大器，而不是内耗的工具。
2. 代码审查背后的设计与拆解：为什么有的团队审了等于没审
2.1 从“审查错误”到“审查理解”：一个核心思路转变
几乎所有团队都会经历这样一个阶段：一开始代码审查是为了抓 bug，大家盯的都是“这里是不是少了个判断”“那里是不是数组越界了”。这种审查方式不能说错，但它有三个很大的问题：
第一，机器能查的，不应该让人来盯。少了个空指针判断、某个方法没有判空、变量命名不规范，这些静态检查工具扫一遍全出来了。人的注意力是稀缺资源，你把它花在工具已经能干的事上，那真正需要人判断的东西反而没人看了。
第二，只看“对不对”会忽略“好不好”。代码“能跑”和“好维护”是两码事。有一次我们团队一个小伙子写了一个 DataFrame 处理的逻辑，跑起来完全没问题，测试也过了，但那个复杂度我盯了十分钟才看懂他到底想干嘛。后来我给他写了一大段评论，不是在说这个功能有什么 bug，而是在问他：“这个逻辑你下次自己看的时候，需要多久能反应过来？如果两个月后有线上问题需要排查，你敢不敢在凌晨三点来看这段代码？”代码审查真正应该盯的，是这种“未来的维护成本”，而不只是当下的正确性。
第三，审查应该是在对齐“设计意图”，而不是单方面挑毛病。好的审查过程，是作者讲清楚“我要解决什么问题、为什么这么设计、有哪些取舍”，审查者基于自己的经验提出“这个方案是否最优、有没有更简洁的写法、有没有潜在的风险”。这两种角色是伙伴关系，不是裁判和被告的关系。
所以我的核心思路转变是：代码审查的产出物不是一段“通过的代码”，而是一个“团队共识”。每次 review 都是一次知识的传递和沉淀。作者在解释自己的方案时，会对代码有更深的理解；审查者在提问时，也会发现自己原有认知里的一些盲区。这个价值，远远超过抓到几个 bug。
2.2 既然要审，那审哪些内容才算“到位”
说得有点抽象，我把它落到具体的审查清单上。我给自己和团队列过一个 review checklist，每次提代码之前，作者先对照跑一遍；审查者也按这个清单过一遍，减少遗漏。清单长这样：
- 逻辑正确性：核心流程是否符合需求预期？有没有漏掉边界条件？数据一致性怎么保证？
- 安全与异常：外部输入有没有校验？异常路径有没有处理？会不会引入注入、越权之类的风险？
- 可读性：命名是否表意清晰？函数是否干了超出职责的事？一个新人来看这段代码，需要多久才能看懂？
- 可维护性：是否留下了必要的注释？接口设计是否合理？有没有在它该在的抽象层级？
- 性能与资源：有没有明显的无效循环、重复查询、内存泄漏隐患？缓存有没有考虑失效策略？
- 测试覆盖：核心分支有没有单测？测试是在验证行为还是在验证实现细节？（后者会变成以后重构的障碍）
- 风格与一致性：和团队现有代码风格是否一致？是否遵循了已有的模式而不是另起炉灶？
注意，这个清单不是让审查者每次都逐项打勾，它更像一个“检查框架”。实际审查中，多数评论会集中在第 2、3、4 类，因为逻辑正确性如果不通过，代码根本不会走到审查环节，CICD 流程和自测就把你拦住了。
2.3 分级审查 + 时间窗口 = 团队节奏的定海神针
前面提到“分级审查”，这是我认为中小团队最可行的一套节奏。大厂那种“任何代码必须征得两位专家同意才能合入”的模式，需要很强的评审资源池支撑，大多数团队根本养不起这个机制。我们的做法是：
- 高风险模块：涉及支付、数据清结算、权限控制、核心存储结构变更，必须指定有经验的 senior 审查，并且最好两个人以上交叉看。
- 中风险业务逻辑：核心流程的迭代，至少要有一个人认真过一遍，重点看逻辑正确性和测试覆盖。
- 低风险改动：文档修订、常量调整、注释更新、纯样式改动，走单审或者直接靠自动化检查，不阻塞合入。
这样区分是有讲究的。如果所有改动都走同样严格的审查流程，团队很快就会疲劳，“审查疲劳”一旦出现，看什么都觉得“还行”，那高风险代码反而得不到足够的关注。
同时，审查时间窗口也很关键。我们团队定了一条规矩：工作时间内，审查请求的响应目标是 2 小时。不是要求 2 小时必须看完，而是 2 小时内必须给出一个明确的态度——“我接了，今天给反馈”或者“我现在没空，你找别人看看”。让人等一天一夜没有回音，是消磨作者积极性的头号杀手。
3. 实操全过程：一次完整 Code Review 是怎么从提 MR 到合入的
3.1 提代码之前的“半小时自审”，能帮你少挨一半的批
很多新人提代码之前不打草稿，直接git push就完事，然后等着被 review 意见淹没。我自己的习惯是：提 MR 之前，先用半小时把自己的 diff 完整过一遍。这个“自审”的时间花得非常值。
怎么自审？我会在本地先把这次改动涉及的文件列出来，逐个打开 diff 看。主要看几个问题：
- 有没有“顺手改”的内容混进来？比如改一个 bug 的时候顺手把旁边一行的格式也调整了，这种“顺手”会在 diff 里产生噪音，让审查者花额外的精力去辨别“这个改动是干嘛的”。
- 有没有没用的代码？改完逻辑后有些注释、临时变量、调试输出可能忘了删，自审的时候删干净，能减少很多尴尬评论。
- commit 信息是否表达了意图？我们的习惯是一个 commit 对应一个逻辑点，每个 commit message 说清楚“为什么做这个改动”，而不是“update”。commit 信息本身也是给人看的，它也属于 review 的一部分。
最后，把这个 MR 的描述写清楚。我的描述模板固定三块：背景（为什么要改）、方案（怎么改的）、测试（验证过什么）。有时候我还会在描述里主动标注“我有疑问的地方”，给审查者直接指出关注点。这样做的好处是沟通成本大幅下降，审查者不用猜你的意图。
3.2 作者视角：把 diff 写成“故事”而不是“代码碎片”
当一个小小的 diff 能被快速看懂时，审查体验就会好很多。我见过一些人提 MR 时，几百行代码混在一起，连标题都写不清楚：“fix”，这种 MR 我看着脑壳都疼。所以现在我会在 MR 描述里加一段“如何阅读这个 MR”的指引：
- 第一个 commit 是加了核心的数据模型；
- 第二个 commit 是改了查询逻辑；
- 第三个 commit 是补了单测；
- 如果你想看整个流程，从第一个 commit 开始读比较顺。
这种“阅读指引”看起来是额外的活，但它极大降低了沟通成本。审查者不需要在几百行 diff 里摸爬滚打，就能快速定位到他想看的模块。尤其当改动涉及跨文件、跨模块时，这种写法几乎是刚需。
同时，如果这个 MR 有一定的设计取舍，我会直接在描述里写出来：为什么这么做，而不是那么做。比如“我本来想用全局状态记录用户登录态，但考虑到多标签页场景，改成了 localStorage + storage 事件同步”，这种“我纠结过”的信息，能让审查者快速理解设计背景，也能让 review 对话聚焦在真正的关键点上，而不是纠缠在“你为什么不那么写”这种信息不对称上。
3.3 审查者视角：我收到 review 请求后实际做了什么
收到一条 review 请求，我一般不会拿起手机就开始看，而是先花十秒钟判断这个 MR 的风险等级和规模。如果它改动超过 400 行，或者动了核心底层逻辑，我不会直接在 MR 页面里零碎地点评论，而是先把代码拉到本地，在 IDE 里顺着调用链走一遍。
为什么要拉到本地看？因为网页 diff 只能看到“改了什么”，看不见“这个改动在完整代码里是怎么被调用的”。尤其是重构类改动，你在网页上看不到整个前因后果，很容易漏掉影响面。在本地看的话，我能跳转到方法定义处，看一下这个函数还有没有其他调用方、数据结构有没有其他消费方。
看的时候，我手里会拿着一张纸（或者开一个笔记软件），我习惯用“一页纸记录法”：把发现的问题分成三类——必须修、建议改、可以不改。
- 必须修：影响正确性的 bug、安全漏洞、明显会让下一个人踩坑的设计、会污染数据一致性的任何问题。
- 建议改：更好的写法、可以进一步封装的逻辑、测试覆盖不足的地方。这些意见我会表达清楚理由，但如果作者给出合理的理由拒绝改动，我不会硬卡着不让合。
- 可以不改：纯风格偏好、比较个人倾向的建议。这类评论我通常只在作者需要的时候才提，或者干脆不写进留言里，怕给作者造成不必要的压力。
写评论的时候，我给自己立了几条规矩：
- 不说“你错了”，说“我理解这里可能有风险”。
- 永远附带理由和场景。比如我会写“这段如果传进来的 list 是空的，后面取第一个元素会直接抛异常，要不要先判空？”这比单纯写“这里要判空”有价值得多。
- 用小规模建议替代大规模重写要求。如果整个方案需要推翻重来，我不会在评论里写一大堆，而是约作者开个 10 分钟的视频或者当面聊，聊完再改。这样沟通效率高，也不会在评论区留下一堆带着情绪的争吵。
3.4 从“提意见”到“达成一致”：一次标准 review 对话实录
我拿我们团队最近一次比较典型的审查对话来举例。这个需求是给列表页加一个筛选功能，作者实现的方案是把筛选条件直接放在前端内存里，页面上有个“重置”按钮。我看了代码后，在 MR 里留了这样一条评论：
我看到筛选条件是在前端内存里维护的状态，那用户刷新页面之后，筛选条件会丢吗？如果产品期望的是“刷新后保持筛选状态”，这里可能需要把条件同步到 URL query 参数里，这样还能支持分享链接直接带筛选结果。你们需求文档里对这块有说明吗？
作者第二天回复：
需求文档里确实没写刷新后的行为，我问过产品了，产品希望刷新后保持筛选条件。那我改成 URL query 同步的方案，但这个需要调整一下路由结构，改动量会大一些。可以的话我单独提一个 MR 来改路由的部分，这个 MR 先合入内存版，然后再跟一个。
我又回复：
可以，不过既然要改成 URL query，那内存版的意义就不大了，不如这个 MR 直接改成 URL query 版本，路由改动如果范围可控，就在这个 MR 里一起做了。你先看看路由改动会影响到哪些页面？如果影响面大，我们再拉个会讨论。
最后作者把路由改动的影响面确认了，影响两个页面，就一起改掉了，MR 直接包含最终方案。整个对话下来，没有谁对谁错的拉扯，就是基于信息逐步对齐，最后得到一个大家都认可的结论。
这就是我眼中“健康的 review 对话”。它有几个共同点：以信息拉齐为主，以业务需求为准绳，以代码质量为底线。这样一轮 review 下来，代码质量提升了，作者对产品场景的理解也更深了，审查者也了解了产品里一些之前没注意到的细节。
4. 工具与流程选型：给“open code review”上点实在的
4.1 工具不是越多越好，关键是“数据能流起来”
很多团队一提代码审查，第一个动作就是装各种工具。Gerrit、Phabricator、GitLab MR、GitHub PR、CR 平台自建……工具确实很多，但我见过很多团队装了 Gerrit 之后，因为它的强制 push 限制和复杂的 refs 规范，开发效率反而跌了一截。
我的观点是，工具选择要跟团队规模和协作习惯匹配，不需要刻意追求复杂。我们现在用的就是 GitLab MR + 一组自动化检查（lint、单测、覆盖率趋势、依赖安全检查）。配合起来的工作流是：
- 开发者在功能分支上开发，提交 MR。
- MR 触发自动化流水线，跑 lint、构建、单元测试、覆盖率采集。
- 流水线全绿后，MR 页面上会出现“可审查”状态，审查者收到通知。
- 审查者看完，提出评论，作者在分支上继续改动，重新推送，流水线重跑。
- 所有评论解决、流水线通过、至少满足该风险等级的审查人数要求后，合入。
这套流程最大的好处是：自动化处理和人工判断的边界非常清晰。凡是机器能确定的规则（代码风格、语法错误、基础测试失败），全部由流水线兜底；凡是需要经验判断的地方（设计是否合理、边界是否覆盖、抽象是否恰当），全部由人工 review 补位。两者互补，既不让机器越权替代人的判断，也不让人去干机器该干的活。
4.2 “open code review”到底该怎么落地
前面提到“open code review”这个热词。我理解它有两层含义：
第一层是代码变更的透明性。不管是谁的代码，团队里的任何一个人都可以看，都可以评论，不需要有特定的头衔或者资历。我们团队有一个做法是可以让技术委员会或者产品、测试人员参与 review。测试同学能指出某些功能无法从代码逻辑上发现的问题；产品同学能澄清需求上的理解偏差。让非开发角色参与 review，本质上是把“质量”这个概念从一个开发内部流程，扩展到整个交付链路。
第二层是审查文化的开放性。队友提的意见，不是“上面派来的指令”，而是“大家一起把代码变得更好”。新人可以给资深工程师的代码提建议——有时候可能是“这里的命名我看不太懂能不能加个注释”或者“这个复杂函数是不是可以拆一下”，这些建议非常有价值。它们代表了“第一次读这段代码的人的直观感受”，而资深工程师往往已经对自己的代码产生了“当局者迷”的效应，自己看不出哪里难懂。
要让这种开放的文化真正落地，有几个现实条件需要保证：
- 评论的语气必须是“非攻击性”的。团队 leader 要在日常做示范，对任何评论都先回应“有道理，我再想一下”，而不是第一反应反驳，这样才会有人敢提不同的声音。
- 不对“提出问题”这件事做任何负面评价。哪怕某个意见确实没有采纳价值，也要认真回复“这个建议考虑过，但因为某某原因不采用”，而不是沉默或者一句“不影响”。
- 新人提了有价值的意见，一定要在公开场合表扬。正向反馈是对开放文化最强有力的支撑。
4.3 别让“流程正确”吃掉了“代码质量”
引入流程和工具久了容易出另一种问题：大家开始为了“过流程”而过流程。比如，流水线要求覆盖率不能低于 80%，作者就去给工具类写一堆毫无意义的 getter/setter 单测来凑数；比如，要求必须有两位审查者通过，那第二位就点个赞走过场。这种现象特别危险，因为它把流程变成了目的，把真正的代码质量放在了一边。
我的应对方式是定期做 review 本身的复盘。每个月会挑一两个已经合入的 MR，大家坐在一起复盘：当时的 review 有没有漏掉关键问题？有哪些问题是在上线后才被发现的？如果当初 review 时多问一句，是不是就能避免？这种复盘不是为了追责，而是为了让流程不断优化，让“质量”成为团队的一种肌肉记忆，而不是流程图上的一个复选框。
顺便说一个我很少在公开资料里看到的操作：建议把“review 意见被采纳数”作为衡量团队协作的一个参考指标——但是不对接绩效。它只用来做团队自我诊断，如果连续几周大家的采纳率都特别低，说明要么是审查意见本身质量不高，要么是团队里存在“防御性代码”文化，需要及时干预调整。但这绝对不能和个人绩效挂钩，一旦挂钩，就会出现刷采纳数的情况，那就彻底跑偏了。
5. 新人怎么参与代码审查 + 常见问题排查实录
5.1 新人看代码看不懂、不敢评论怎么办
刚进团队的新人，最容易陷入两个极端：要么完全不敢看别人的代码，觉得自己什么都不懂，看也是浪费时间；要么什么都要点个赞评两句，又拿不出建设性意见。这两个极端都不可取。
我给团队新人建议的路径是三步走：
第一步：看语法，理结构。不需要尝试看懂业务逻辑，只做一件事：把整个 MR 涉及的代码文件打开，搞清楚每个文件是干什么的，类之间的关系是什么。这一步主要目的是熟悉代码库，不是你给 MR 提意见，而是让 MR 带你去认识代码。
第二步：看测试，理解行为。跳过实现代码，先看单测。单测是代码行为的活文档，单测里描述了“这个函数在哪些输入下应该得到什么输出”。你不需要完全理解每个分支，只需要理解主要场景就够了。如果你发现某个核心场景没有对应的单测，这就是一个很好的评论点：“这里的逻辑看起来相当重要，但没看到对应的测试覆盖，能补一个吗？”
第三步：带着问题提问。把疑问写在评论区，不需要下结论。比如“这个函数看起来超长，是不是可以拆一下”“这个变量名我第一眼看成另一个意思了，能不能换一个更明确的命名”。这些问题也许在资深工程师看来很初级，但对团队来说恰恰是“外部视角”的宝贵反馈——因为它们代表了未来阅读这段代码的普通人的真实困惑。
5.2 作者状态不佳、情绪化时怎么处理
代码审查里最尴尬的瞬间，就是你明明提的是合理的意见，对方却觉得你在否定他这个人。这种情况每个人都遇到过，包括我自己。
我现在的原则是：Review 里绝对不出现“你”字。不说“你这里写得有问题”，而是说“这段逻辑在某某场景下可能会出问题，建议加一个保护”。把焦点从“你”转移到“代码”上。作者的状态如果看起来情绪确实有点激动，我不会在评论区继续拉扯，我会把评论改成一个简单的“写得挺好，就是这里我不确定怎么处理，咱们同步一下”，然后拉个会，10 分钟就能把问题聊开。因为文字没有语气，很多原本没问题的表达方式在文字里都会被读成攻击。
另外，作为作者，如果觉得审查意见有误，也要学会温和地提出反驳。可以这么写：“我理解你的担心，但这里的调用链保证了前面肯定已经判过空了，你看是不是不需要再判？”这种情况下，最好的结果是审查者发现确实是自己漏看了上下文，会道歉并撤回评论。谁都会有看错的时候，大大方方承认，反而能加深团队的信任。
5.3 我在真实项目里踩过的坑：一次覆盖率没达标导致的上线事故
说一个我印象最深的事故。有一次我们做一个数据导出功能，我在 review 时看到作者把导出格式的判断逻辑写得有点绕，而且最关键的一个分支没有单测覆盖。我当时提了意见说“这个分支最好补个测试”，但因为当时正处于发版窗口截止时间，作者说“这个分支太偏了，线上很难触发，先合吧，下个迭代补”。我一时心软就放行了。
结果上线第二天，正好有一个用户的数据是特殊格式，触发了那个分支，导出出来的文件里某个字段格式全部错乱，客服邮箱被塞满了投诉。问题本身倒是不复杂，十分钟就能定位修复，但影响的是客户的信任和团队加班的晚上。
从那以后我给自己立了一个死规矩：Review 卡住的东西，如果不是在当期必须修的，可以放；但是对“影响数据正确性”的分支没有测试覆盖这件事，绝对不松口。宁可让这个 MR 晚一天合入，也不能把“未经过验证的数据处理逻辑”放进主干。
5.4 一个月后回看：有些评论根本不用写
有这个体会是在我做了大量 review 之后。有时候评论写得很爽，但过一个月再回看当时那个 MR，发现我提的三条意见里，有两条其实是“风格偏好”而非“本质问题”：
比如我让作者把函数封装得更小一点，但实际上那段代码总共只有十五行，再拆下去反而更碎；又比如我建议用更高级的某个语法写法来简化逻辑，但那个写法会让新人读起来更难懂。这类“为了优雅而优雅”的意见，其实是在给团队制造认知负担。
现在我给自己定了一条原则：评论如果不是“能显著降低未来维护成本”或者“修复了某个具体风险”，那就先留在心里，等两周后再看自己还记不记得这条意见。如果两周后我完全忘了，说明它根本不重要。这个原则帮我把川流不息的“我觉得可以优化”的冲动压了下来，让我每次真正发表的评论都更有分量。
这个经验也想分享给所有容易“评论上瘾”的工程师：代码审查的目标是让代码库越来越好，不是让你的每条意见都被采纳。少说两条不痛不痒的话，你的重要意见反而会得到更多重视。
6. 给团队推行 Code Review 的几条实在建议
如果你正准备在团队里推行或者优化代码审查流程，我这几年踩出来的经验可以浓缩成几条：
- 先解决工具链，再讨论制度。没有自动化的静态检查、单测、CI 流水线兜底，人工审查会不堪重负，Review 很快会变成摆拍。先把能自动化的全部自动化。
- 从小范围试点开始。找一两个核心项目，先跑一个月，把节奏、模版、问题类型都磨得差不多了，再全团队推广。不要上来就铺开，容易翻车。
- 让每个 MR 尽量小。几百行的 MR 审起来是负担，几十行的 MR 审起来是享受。如果团队里经常出现上千行的巨型 MR，那问题不在审查本身，而在需求拆分和代码设计上，得往前端流程找根因。
- 把 review 时间算进开发排期里。很多团队排期只算了写代码的时间，没算 review 和修改的时间，导致 reviewer 和 author 互相挤压时间，最后 review 质量一定下降。比较好的做法是，在估点的时候明确留出 20% 的 buffer，专门用来做审查和修改。
- 定期复盘，而不是等人抱怨。每两周在团队周会上花十分钟，快速回顾这段时间的 review 情况，有问题及时调整。
说到底，代码审查不是“为了合规而做”的管理动作，它在软件开发里扮演的更像是“质量守门员 + 知识传播者 + 工程文化塑造者”三合一的角色。那些真正把代码审查做好的团队，代码库会越来越干净，团队会越来越默契，新人的成长速度也会显著加快。
我个人最深的体会是：当你从“被审查的人”变成“渴望被别人审查的人”那一刻起，你的代码水平才真正开始快速提升。因为你会意识到，代码永远有更好的写法，而别人眼中看到的你的代码，才是它真实的样子。
