1. 为什么我们需要重新审视代码审查这件事代码审查这件事做了十几年我最大的感受是它从来不是技术问题而是协作问题。很多人以为代码审查就是找bug其实找bug只是副产品真正的价值在于知识传递、规范落地和风险前置。但现实情况是大部分团队的代码审查要么流于形式——点个approve就完事要么变成战场——两个人为了一个命名风格吵得不可开交。open-code-review这个项目标题本身就很有意思。它不是一个具体的工具名而是一个动作、一种理念。我理解它至少包含三层含义第一审查过程要开放透明不是小圈子里的暗箱操作第二审查工具要开源可定制不是被某个商业平台绑架第三审查文化要开放包容对事不对人。这三层缺一不可少了任何一层代码审查都会变成团队里的“必要之恶”。我见过太多团队在代码审查上踩坑。有的团队用商业平台的PR功能结果被按人头收费搞得预算紧张有的团队自己搭了一套审查流程结果因为工具太复杂大家宁愿直接push到主分支还有的团队审查标准不统一同一个人写的代码张三审就过李四审就打回。这些问题的根源都不是技术而是没有想清楚“为什么要审查”和“怎么审查才可持续”。这篇文章适合三类人看一是正在搭建或重构代码审查流程的技术负责人二是被代码审查折磨得死去活来的普通开发者三是对开源协作模式感兴趣、想了解如何把开源理念引入内部团队的人。我会从设计思路、核心细节、实操落地、问题排查四个维度把open-code-review这件事拆开揉碎讲清楚。不管你现在用的是GitLab、GitHub还是自建的Gerrit底层逻辑都是相通的。2. 代码审查体系的整体设计与思路拆解2.1 审查流程的三种模式与选型逻辑代码审查的流程设计本质上是在“速度”和“质量”之间找平衡点。我总结下来无非三种模式同步审查、异步审查和混合审查。同步审查就是两个人坐在一起一个人讲一个人看实时沟通。这种方式效率极高特别适合复杂逻辑的评审比如算法实现、架构调整。但问题也很明显——时间成本太高两个人必须同时有空而且容易变成“讲的人主导看的人附和”。我早期带团队时用过这种方式结果就是每天下午固定两小时“审查会”大家怨声载道。异步审查就是现在主流的PR/MR模式提交代码后等别人来看评论、修改、再评论。这种方式灵活不占用整块时间但缺点是反馈周期长有时候一个简单的改动要等一两天才能合并。更麻烦的是异步审查容易变成“橡皮图章”——审查者扫一眼就点通过根本没仔细看。混合审查是我目前最推荐的方式小改动走异步大改动走同步。具体来说改动行数少于50行、不涉及核心逻辑的直接异步审查要求4小时内必须有人响应改动行数超过200行、或者涉及数据库schema、公共接口、安全相关的必须安排一次30分钟的同步评审。这个分界线怎么定我的经验是看“认知负荷”——审查者需要花多少脑力才能理解这个改动。如果看一眼就能明白异步就够了如果需要反复读几遍才能理解上下文那就值得同步沟通。open-code-review理念下我建议把审查模式的选择权交给提交者但要有明确的指导原则。提交者在创建PR时可以勾选“需要同步评审”或“异步即可”并附上理由。审查者如果觉得判断有误可以要求升级为同步评审。这样既尊重了提交者的判断又保留了纠偏机制。2.2 工具链选型从商业平台到自建方案工具选型这件事我踩过的坑最多。早期用商业平台功能确实完善但有几个致命问题一是按人头收费团队扩张时成本线性增长二是数据在别人服务器上安全合规过不了三是定制化能力有限想加个自定义检查规则都要求爷爷告奶奶。后来转向自建方案用GitLab CE Jenkins SonarQube搭了一套。GitLab负责代码托管和MR管理Jenkins跑CI流水线SonarQube做静态分析。这套组合的好处是全部开源、可定制、数据在自己手里。但缺点也很明显维护成本高GitLab升级一次要折腾半天Jenkins的插件依赖经常出问题SonarQube的规则配置需要专门学习。open-code-review理念下我更倾向于“轻量级自建”方案。核心组件只需要三个Git服务 CI引擎 通知系统。Git服务用Gitea或GitLab CE都行Gitea更轻量GitLab功能更全。CI引擎用Drone或Woodpecker比Jenkins简单太多配置文件就是YAML学习曲线平缓。通知系统用Matrix或Mattermost开源且可自托管。这里有个关键决策点要不要引入静态分析工具。我的建议是分阶段来。团队少于10人时先别上SonarQube用语言自带的linter就够了比如Python的ruff、JavaScript的eslint、Go的golangci-lint。这些工具配置简单运行快误报少。等团队超过20人、代码量超过10万行时再考虑引入SonarQube做全局质量门禁。注意自建方案最大的风险不是技术而是“没人维护”。我见过太多团队兴致勃勃搭了一套结果半年后没人升级、没人修最后变成技术债。所以搭之前先问自己有没有专人负责维护如果没有宁可先用商业平台等团队有精力了再迁移。2.3 审查标准的制定与落地策略审查标准这件事最怕两种极端一种是“什么都管”从命名风格到架构设计都要审结果审查者累死提交者烦死另一种是“什么都不管”只要CI过了就合并结果代码质量直线下降。我的经验是审查标准要分层不同层级用不同机制。第一层是“机器能查的”比如代码格式、语法错误、明显的安全漏洞这些交给linter和CI不占用人工审查时间。第二层是“机器查不了的”比如逻辑正确性、边界条件处理、性能影响这些必须人工审查。第三层是“机器和人都难查的”比如架构合理性、可维护性、业务语义一致性这些需要资深开发者参与而且往往需要同步沟通。open-code-review理念下审查标准应该是“活文档”不是一成不变的。我建议每个团队维护一个REVIEW_GUIDELINES.md文件放在代码仓库根目录。这个文件里写清楚哪些是必须检查的比如“所有公共函数必须有文档注释”哪些是建议检查的比如“尽量使用早返回减少嵌套”哪些是不用检查的比如“变量命名风格由linter统一”。每次审查中发现新的共性问题就更新这个文件。这样标准会越来越完善而不是越来越臃肿。还有一个实操技巧把审查标准变成检查清单。人脑不擅长记忆长列表但擅长对照清单逐项检查。我通常会把审查标准浓缩成10条以内的检查清单放在PR模板里。提交者创建PR时自动带上这个清单审查者逐项打勾。比如[ ] 改动是否有对应的测试用例[ ] 是否处理了边界条件和异常情况[ ] 是否有性能敏感的操作如循环内查数据库[ ] 是否更新了相关文档[ ] 是否有安全风险如SQL注入、XSS这个清单不需要太长太长就没人看了。10条以内每条都是“是/否”能回答的不要写“请确保代码质量良好”这种模糊表述。3. 核心细节解析与实操要点3.1 如何写出让审查者舒服的PR描述PR描述这件事90%的开发者都做得不好。我见过太多PR描述就一句话“修复bug”或者“添加功能”。这种PR让审查者怎么审只能去读diff而diff往往几百行读起来费劲还容易漏掉关键改动。一个好的PR描述应该包含四个部分背景、改动内容、测试情况、审查重点。背景说明为什么要做这个改动比如“用户反馈登录后偶尔跳转到404页面”。改动内容说明具体改了什么比如“在登录成功回调中增加了路由守卫确保跳转前检查目标路由是否存在”。测试情况说明你怎么验证的比如“本地跑了100次登录流程未复现404新增了3个单元测试覆盖边界情况”。审查重点告诉审查者应该关注哪里比如“请重点看路由守卫的逻辑是否正确特别是异步路由加载的场景”。open-code-review理念下PR描述还应该包含“审查者指引”。比如“这个PR改动较大建议先看auth.js的改动再看router.js最后看测试文件。如果时间有限可以只看auth.js的validateRedirect函数。” 这种指引能大幅降低审查者的认知负荷让审查更高效。我自己的习惯是PR描述里还会加一个“自查清单”列出我已经检查过的项。比如“已确认无硬编码密钥、已确认无console.log残留、已确认测试覆盖率未下降”。这不仅是给审查者看的也是给自己看的——写这个清单的过程就是一次自查。提示PR描述不要写“根据需求文档XXX”因为需求文档可能只有你有权限看。审查者需要的是自包含的上下文不是指向另一个文档的链接。如果确实需要引用外部文档把关键内容摘录到PR描述里。3.2 审查评论的措辞技巧与沟通策略审查评论的措辞直接决定了代码审查是“建设性反馈”还是“人身攻击”。我见过太多因为一句话没说好导致两个人结仇的案例。比如“这代码写得有问题”和“这里可能有个边界情况没处理建议加个判断”意思一样但效果天差地别。我的经验是评论要针对代码不要针对人。永远说“这个函数在输入为空时会崩溃”不要说“你没处理空输入”。永远说“建议把这段逻辑抽成独立函数方便测试”不要说“你写的代码太乱了”。前者是客观描述后者是主观评价。还有一个技巧区分“必须改”和“建议改”。我通常用前缀来区分[must]表示必须修改否则不能合并[suggest]表示建议修改但不阻塞合并[question]表示我不确定想请教一下[nit]表示吹毛求疵改不改都行。这样提交者一眼就能看出哪些是硬性要求哪些是软性建议。open-code-review理念下审查评论还应该包含“为什么”。不要只说“这里要加锁”要说“这里要加锁因为多个goroutine会并发写这个map不加锁会导致panic”。解释原因不仅能帮助提交者理解也能帮助未来的代码阅读者理解。我见过太多代码里的“魔法操作”就是因为当初审查时只说“要这样改”没说“为什么要这样改”结果后人不敢动、也看不懂。对于有争议的评论我的建议是及时升级到同步沟通。异步评论容易产生误解文字没有语气同样一句话可以读成友善的也可以读成讽刺的。如果来回评论超过三轮还没达成一致直接约个15分钟的视频或语音把问题说清楚。这比继续打字高效得多。3.3 审查者的选择与轮换机制审查者选谁这件事看似简单其实很有讲究。选得太随意审查质量没保证选得太固定又容易形成小圈子。我见过一个团队所有PR都必须由Tech Lead审结果Tech Lead成了瓶颈PR平均等待时间超过24小时。我的建议是每个模块指定2-3个“代码所有者”PR必须由至少一个代码所有者审查通过。代码所有者不一定是职位最高的人而是最熟悉这个模块的人。这样既保证了审查质量又避免了单点瓶颈。代码所有者名单放在CODEOWNERS文件里GitLab和GitHub都支持自动根据文件路径分配审查者。open-code-review理念下审查者还应该定期轮换。我通常建议每季度轮换一次代码所有者让更多人有机会深入理解不同模块。轮换的好处是多方面的一是避免知识垄断二是培养更多人的审查能力三是让代码所有者保持新鲜感不会因为长期审同一模块而麻木。对于新人我建议采用“影子审查”机制。新人先作为“观察者”参与审查看资深开发者怎么审、怎么评论但不要求他发表意见。等看了10-20个PR后再开始正式审查但前几个PR由导师复核。这样新人能快速学习审查标准又不会因为经验不足而给出误导性评论。注意不要让同一个人同时审查太多PR。我做过统计一个审查者同时处理超过3个PR时审查质量会明显下降——评论变少、通过率变高、漏掉的bug变多。所以如果发现某个审查者积压了太多PR要么帮他分流要么给他时间集中处理。4. 实操过程与核心环节实现4.1 从零搭建一套轻量级代码审查流水线假设你现在要从零搭建一套代码审查流水线我以Gitea Drone Mattermost这套组合为例把完整步骤走一遍。这套方案的特点是全部开源、全部可自托管、配置简单、维护成本低。第一步部署Gitea。Gitea是一个轻量级的Git服务用Docker部署只需要一条命令docker run -d --name gitea \ -p 3000:3000 -p 222:22 \ -v /data/gitea:/data \ -v /etc/timezone:/etc/timezone:ro \ -v /etc/localtime:/etc/localtime:ro \ gitea/gitea:latest部署完成后通过浏览器访问http://your-server:3000完成初始配置。关键配置项数据库用SQLite小团队够用禁用注册由管理员手动创建账号开启PR功能。第二步部署Drone。Drone是一个CI引擎和Gitea集成很简单。先创建一个OAuth应用在Gitea的Settings Applications里然后部署Dronedocker run -d --name drone \ -p 8000:8000 \ -e DRONE_GITEA_SERVERhttp://your-gitea-server:3000 \ -e DRONE_GITEA_CLIENT_IDyour-client-id \ -e DRONE_GITEA_CLIENT_SECRETyour-client-secret \ -e DRONE_RPC_SECRETyour-rpc-secret \ -e DRONE_SERVER_HOSTyour-drone-server:8000 \ -e DRONE_SERVER_PROTOhttp \ drone/drone:latest然后在项目根目录创建.drone.yml定义CI流水线kind: pipeline type: docker name: default steps: - name: lint image: python:3.11 commands: - pip install ruff - ruff check . - name: test image: python:3.11 commands: - pip install -r requirements.txt - pytest --covsrc --cov-reportterm - name: notify image: plugins/matrix settings: homeserver: https://your-matrix-server roomid: your-room-id username: your-bot-username password: from_secret: matrix_password这个流水线做了三件事跑linter、跑测试、发通知。当PR创建或更新时Drone自动触发流水线结果会回写到Gitea的PR页面。第三步配置Mattermost通知。Mattermost是一个开源的团队沟通工具和Drone集成后每次CI完成都会在指定频道发消息。这样审查者不用一直盯着Gitea有通知了再去看。第四步配置分支保护。在Gitea的仓库设置里开启分支保护主分支不允许直接push必须通过PR合并PR必须至少有一个审查者approveCI必须通过。这三条是底线缺一不可。这套方案搭下来熟练的话半天就能搞定。成本方面一台2核4G的云服务器就够跑全部服务一年也就几百块钱。相比商业平台按人头收费省下来的钱够买好几台服务器了。4.2 审查流程的自动化与半自动化实现代码审查有很多重复性工作能自动化的尽量自动化。我总结了几类可以自动化的检查第一类格式检查。用linter自动检查代码格式不符合的直接打回。这类检查不需要人工参与CI里跑一下就行。关键是配置要合理不要过于严格。比如Python的ruff我通常只开启E错误、F警告、I导入排序三类规则W风格建议和C复杂度先不开等团队适应了再逐步加。第二类测试覆盖率检查。用pytest-cov或jest --coverage生成覆盖率报告设置一个阈值比如80%低于阈值就CI失败。但要注意覆盖率不是越高越好有些代码如配置文件、类型定义不需要测试。我通常会把不需要测试的文件排除掉只对核心业务逻辑要求覆盖率。第三类安全扫描。用banditPython或npm auditJavaScript扫描已知的安全漏洞。这类工具误报率较高建议只扫描高危漏洞中低危的作为警告不阻塞合并。第四类依赖检查。检查是否有过时的依赖、是否有已知漏洞的依赖。用dependabot或renovate自动创建升级PR审查者只需要点合并就行。open-code-review理念下自动化检查的结果应该直接展示在PR页面而不是藏在CI日志里。Gitea和GitLab都支持在PR页面显示CI状态和覆盖率变化。我通常还会配置一个bot自动在PR里评论覆盖率变化“覆盖率从85.2%下降到84.8%下降了0.4个百分点”。这样审查者一眼就能看到质量变化。对于半自动化我推荐用PR模板 检查清单。在仓库根目录创建.gitea/PULL_REQUEST_TEMPLATE.md内容如下## 改动背景 !-- 为什么要做这个改动 -- ## 改动内容 !-- 具体改了什么 -- ## 测试情况 !-- 怎么验证的 -- ## 自查清单 - [ ] 已跑通本地测试 - [ ] 已确认无硬编码密钥 - [ ] 已确认无调试代码残留 - [ ] 已更新相关文档 ## 审查重点 !-- 希望审查者重点关注哪里 --这个模板强制提交者思考四个问题为什么改、改了什么、怎么验证的、希望看哪里。写清楚这四个问题审查效率至少提升一倍。4.3 审查数据的度量与持续改进代码审查做得好不好不能凭感觉要有数据。我通常关注四个指标PR平均大小、审查响应时间、审查评论密度、PR合并周期。PR平均大小用改动行数衡量。我的经验值是200行以内最佳超过400行审查质量明显下降。如果发现团队PR平均大小超过300行就要考虑拆分PR了。拆分的原则是“一个PR只做一件事”比如“重构用户模块”和“添加用户导出功能”应该分成两个PR。审查响应时间指从PR创建到第一条评论的时间。这个指标反映团队的响应速度。我的目标是4小时内超过8小时就说明审查者可能太忙或者没看到通知。改进方法配置更醒目的通知如Mattermost的here或者设置轮值审查者。审查评论密度指每个PR的平均评论数。这个指标不是越高越好太高说明代码问题多太低说明审查者没认真看。我的经验值是小PR50行1-3条评论中PR50-200行3-8条评论大PR200行8-15条评论。如果发现某个审查者的评论密度持续偏低可能需要提醒他认真审查。PR合并周期指从PR创建到合并的时间。这个指标反映整体效率。我的目标是24小时内超过48小时就要分析原因是审查者太忙是提交者响应太慢还是改动太复杂需要反复讨论open-code-review理念下这些数据应该公开透明。我通常会在团队周会上展示上周的审查数据让大家看到趋势。但要注意数据是用来改进的不是用来考核的。如果用来考核大家就会刷数据——把PR拆得特别小、评论写得特别多、响应特别快但质量反而下降。提示度量指标不要超过5个太多就没人看了。而且指标要稳定不要频繁更换。我见过一个团队每个月换一套指标结果大家都不当回事。选3-5个核心指标持续跟踪半年才能真正看到改进效果。5. 常见问题与排查技巧实录5.1 审查者不响应或响应太慢怎么办这是代码审查中最常见的问题。PR创建后审查者迟迟不看提交者干等着项目进度卡住。我遇到过最夸张的情况一个PR等了三天没人审最后提交者直接push到主分支了。排查这个问题的第一步是确认通知是否送达。很多团队用邮件通知但邮件容易被淹没在收件箱里。我建议用即时通讯工具通知比如Mattermost、Slack或飞书。通知里要包含PR链接、改动摘要和审查者名字让审查者一眼就知道需要他做什么。第二步是确认审查者是否太忙。如果某个审查者同时被分配了太多PR他可能根本看不过来。这时候需要分流——把部分PR转给其他审查者或者临时增加审查者。我通常会在团队里维护一个“审查者负载表”记录每个人当前待审的PR数量超过3个就不要再分配新PR了。第三步是建立升级机制。如果PR超过4小时没人响应提交者可以审查者或团队频道提醒。超过8小时没人响应可以升级到Tech Lead由Tech Lead指定审查者或自己审。这个机制要写进团队规范让大家都知道。open-code-review理念下审查响应应该是双向责任。审查者有责任及时响应提交者也有责任让PR易于审查。如果PR描述不清、改动太大、没有测试审查者可以要求提交者先完善再审查。我通常会在PR模板里加一条“如果PR描述不完整审查者有权直接打回不占用审查时间。”还有一个技巧是设置“审查时段”。我见过一个团队每天上午10点和下午3点各花30分钟集中审查PR。这段时间大家都不写代码专门看PR。这样审查者不会被自己的开发任务打断审查效率更高。提交者也知道什么时候能拿到反馈不用一直等。5.2 审查意见分歧太大怎么处理审查意见分歧是好事说明大家在认真思考。但如果分歧太大导致PR迟迟无法合并就成了问题。我见过两个资深开发者为了一个设计模式争论了一周最后PR被放弃功能重新实现了一遍。处理分歧的第一步是区分“事实分歧”和“偏好分歧”。事实分歧是关于“哪个方案正确”的争论比如“这个函数在输入为负数时会崩溃”vs“不会崩溃”。这种分歧可以通过写测试来验证——写个测试用例跑一下谁对谁错一目了然。偏好分歧是关于“哪个方案更好”的争论比如“用策略模式还是用if-else”。这种分歧没有绝对的对错取决于具体场景和团队习惯。对于偏好分歧我的建议是设定决策规则。比如如果分歧涉及公共接口由Tech Lead决定如果涉及模块内部实现由代码所有者决定如果涉及代码风格由linter决定。规则定好了大家按规则来不用每次争论。open-code-review理念下分歧应该公开讨论而不是私下解决。我见过太多团队在私聊里达成一致然后在PR里假装没有分歧。这样其他团队成员就失去了学习的机会。公开讨论的好处是一是让更多人了解不同方案的优劣二是避免“私下交易”导致的标准不一致三是留下决策记录方便后人查阅。如果公开讨论超过三轮还没达成一致我建议升级到同步会议。15分钟的视频或语音把问题说清楚往往比打一天字更有效。会议的目标不是“谁说服谁”而是“找到一个双方都能接受的方案”。如果实在找不到就按决策规则来由指定的人拍板。注意不要为了“和谐”而回避分歧。我见过一个团队审查者明明觉得方案有问题但为了不伤和气就点了通过。结果上线后出了故障回头一看当初审查者其实已经发现了问题。这种“和谐”是假和谐最终伤害的是产品和团队。5.3 审查流于形式怎么破审查流于形式是最难解决的问题。表现是审查者秒点通过、评论只有“LGTM”Looks Good To Me、PR合并后频繁出bug。我见过一个团队PR平均审查时间不到2分钟评论数不到1条但线上故障率居高不下。排查这个问题的第一步是看数据。如果PR平均审查时间低于5分钟、评论数低于1条、但bug率高于行业平均那基本可以确定审查流于形式了。这时候需要深入分析是审查者太忙是审查标准不清晰还是审查文化没建立起来第二步是抽样检查。随机抽取几个已合并的PR让资深开发者重新审查一遍看看能发现多少问题。如果发现的问题数量明显多于原审查者说明审查质量确实有问题。我通常建议每月做一次抽样检查作为质量监控的一部分。第三步是建立正向激励。审查流于形式的根本原因是“审查好没奖励审查差没惩罚”。我建议把审查质量纳入绩效考核但不是简单看评论数而是看“审查发现的有效问题数”和“审查后bug率”。同时对于审查认真的开发者公开表扬比如在周会上说“张三上周在审查中发现了3个潜在的生产事故避免了重大损失”。open-code-review理念下审查流于形式的根本解法是让审查变得有价值。如果审查者觉得审查是“额外负担”那永远做不好。要让审查者觉得审查是“学习机会”——通过审查别人的代码了解不同模块的实现提升自己的技术视野。我通常会在团队里强调“审查不是帮别人干活是帮自己学习。”还有一个实操技巧是限制PR大小。如果PR太大审查者一看就头疼自然就秒点通过了。我建议在CI里加一个检查如果PR改动超过400行自动打上“需要拆分”的标签并提醒提交者拆分。拆分后的小PR审查者更愿意认真看。5.4 常见问题速查表问题现象可能原因排查方法解决方案PR长时间无人审查通知未送达或审查者太忙检查通知配置和审查者负载改用即时通讯通知设置审查者负载上限审查评论只有LGTM审查标准不清晰或审查者不认真抽样检查已合并PR制定检查清单建立正向激励PR反复修改无法合并分歧太大或标准不统一分析评论记录区分事实分歧和偏好分歧设定决策规则升级到同步会议审查后频繁出bug审查流于形式或测试不足统计bug率和审查评论密度加强自动化测试限制PR大小审查者之间标准不一致缺乏统一规范对比不同审查者的评论维护REVIEW_GUIDELINES.md定期对齐新人不敢审查缺乏经验和信心观察新人审查参与度影子审查机制导师复核PR描述太简略缺乏模板和引导检查PR描述完整度配置PR模板强制填写关键信息CI经常失败流水线配置问题或环境不一致查看CI日志统一开发环境优化流水线配置这张表是我从多年实践中总结出来的基本上覆盖了代码审查中80%的问题。遇到问题时先对照这张表排查往往能快速定位原因。6. 我个人的一些实操心得代码审查这件事做了十几年我最大的体会是工具和流程都是次要的文化才是根本。我见过用着最简陋工具但审查质量极高的团队也见过用着最先进平台但审查流于形式的团队。区别不在于工具而在于团队是否真正重视代码质量是否愿意为审查投入时间。open-code-review这个理念最打动我的地方是“开放”二字。审查过程开放意味着每个人都能看到代码是怎么被审查的新人能从中学习老人能互相监督。审查工具开放意味着不被商业平台绑架可以根据团队需求自由定制。审查文化开放意味着对事不对人评论针对代码不针对人。如果你正在搭建或重构代码审查流程我的建议是从小处着手先跑起来再优化。不要一开始就追求完美的流程和工具先用最简单的方案比如Gitea Drone跑起来让团队养成审查习惯然后再逐步优化。我见过太多团队在选型阶段纠结了几个月结果什么都没搭起来。最后分享一个我一直在用的小技巧每周花15分钟回顾上周的审查评论。看看哪些评论是有效的帮助发现了问题哪些是无效的吹毛求疵或误解哪些是缺失的事后发现了但审查时没发现。这个回顾不需要正式会议自己看看就行。坚持几个月你会发现自己和团队的审查水平都在提升。代码审查不是目的写出更好的代码才是。open-code-review也好其他理念也好最终都要落到“让代码质量更高、让团队协作更顺”这个目标上。工具会变流程会变但这个目标不会变。
