作为开发者我们写好代码、点下 “Create pull request” 的那一刻心里想的通常是“搞定赶紧合并我要去看下一个任务了。”然而现实往往是你的 PR 挂在那里几天甚至几周无人问津或者一打开就塞满了密密麻麻的修改意见。在 CppCon 2025 的一场闪电演讲中资深开发者 Ben Deane 站在代码作者Code Author的角度分享了如何通过“利他”的方式来“利己”——也就是说如何让你的代码变得极易被审查从而加速合并流程。以下是我从这场演讲中提炼的核心干货与思考。1. 动手之前先聊 15 分钟No Surprises很多时候代码审查卡住是因为设计方向发生了分歧。当你花了三天写完几百行代码审查者却说“这个架构不对”时痛苦便产生了。核心原则在动笔前你对代码还没有“情感寄托”。此时改变方向代价几乎为零。行动点每周花 15 分钟找团队里的资深同事或搭档口头沟通一下“嘿关于这个功能我打算这么设计你觉得怎么样”收益提前达成共识确保你在正确的道路上前进。当 PR 真正提交时审查者对你的设计早有心理预期。2. 拒绝“代码墙”把 Commit 拆小不要试图用一个巨大的 Commit 震惊审查者。让人面对几千行的变动只会让审查变成一种折磨。保持 Commit 小而独立一个 PR 可以包含多个 Commit。理想情况下每一个 Commit 都要能编译通过并且通过所有测试。这不仅方便审查也极大地方便了未来的git revert或git bisect。分离机械性修改诸如代码格式化Reformatting、引入新的 Linting 规则、或者大面积的重命名。它们虽然影响的文件多但逻辑极其公式化。单独建一个 Commit 放这些别和业务逻辑混在一起。拒绝“路过式修复”Drive-by fixes顺手改掉的隔壁文件的 Bug另外开 Commit或者另外开 PR。3. 精通你的 Git 本地历史重构Ben Deane 在演讲中提到如果你用 Git 却不修改本地提交历史那你其实没发挥出 Git 的真正威力。优秀的代码作者其本地提交历史在开发时可能是混乱的但在推送到远端之前一定会经过精心的“修剪”。善用工具熟练使用git add -p/git add -i来交互式暂存代码以及git rebase -i来合并squash、拆分split或重排你的本地 Commit。不要只写单行 Commit 信息好的 Commit 信息应该清晰交代三个问题你修复/添加了什么你选择了什么解决方案为什么这么做这是最核心的 context4. 编写不可妥协的、精简的测试测试是审查者的第一道防线。有时候审查者甚至会先从看你的测试代码开始以此来理解你的业务边界。拒绝臃肿如果你的一个测试需要 20 行的 Mock 模板代码Boilerplate才能换来一个断言Assertion那说明测试设计得不够清晰。铁律如果你是在修复一个 Bug必须包含一个能稳定复现该 Bug 的测试用例。这是不可妥协的Not negotiable。5. 主动出击在自己的 PR 上写“导游词”PR 提交后不要干等着。你可以成为自己代码的“导游”。在现实开发中由于时间或技术限制我们难免会在代码里做一些妥协Compromise。与其等着审查者揪出来盘问不如主动说明。行动点在提交 PR 后自己先浏览一遍代码在有疑虑、复杂、或者做了折中的地方自己给自己留评论“注意这里因为系统 A 的限制我做了这样的处理未来可以如何优化……”引入规范推荐团队采用Conventional Comments规范在评论前加上[task]、[suggestion]或[question]明确球在谁的脚下。结语想要高效先学会 reciprocate互惠最后Ben Deane 提到了一个非常朴素的道理如果你希望别人能及时、高质量地帮你审查代码你也必须为他人付出。把代码审查变成你每日工作流的一部分。每天早上开启工作时先从你的 Notifications 标签页开始帮团队成员看几个 PR。当你营造了这种高效互助的团队文化你自己的 PR 合并速度自然也会起飞。你对代码审查有什么心得或者深恶痛绝的痛点吗欢迎在评论区留言讨论
别再给审查者扔“代码墙”了：高效通关 Code Review 的作者生存指南
作为开发者我们写好代码、点下 “Create pull request” 的那一刻心里想的通常是“搞定赶紧合并我要去看下一个任务了。”然而现实往往是你的 PR 挂在那里几天甚至几周无人问津或者一打开就塞满了密密麻麻的修改意见。在 CppCon 2025 的一场闪电演讲中资深开发者 Ben Deane 站在代码作者Code Author的角度分享了如何通过“利他”的方式来“利己”——也就是说如何让你的代码变得极易被审查从而加速合并流程。以下是我从这场演讲中提炼的核心干货与思考。1. 动手之前先聊 15 分钟No Surprises很多时候代码审查卡住是因为设计方向发生了分歧。当你花了三天写完几百行代码审查者却说“这个架构不对”时痛苦便产生了。核心原则在动笔前你对代码还没有“情感寄托”。此时改变方向代价几乎为零。行动点每周花 15 分钟找团队里的资深同事或搭档口头沟通一下“嘿关于这个功能我打算这么设计你觉得怎么样”收益提前达成共识确保你在正确的道路上前进。当 PR 真正提交时审查者对你的设计早有心理预期。2. 拒绝“代码墙”把 Commit 拆小不要试图用一个巨大的 Commit 震惊审查者。让人面对几千行的变动只会让审查变成一种折磨。保持 Commit 小而独立一个 PR 可以包含多个 Commit。理想情况下每一个 Commit 都要能编译通过并且通过所有测试。这不仅方便审查也极大地方便了未来的git revert或git bisect。分离机械性修改诸如代码格式化Reformatting、引入新的 Linting 规则、或者大面积的重命名。它们虽然影响的文件多但逻辑极其公式化。单独建一个 Commit 放这些别和业务逻辑混在一起。拒绝“路过式修复”Drive-by fixes顺手改掉的隔壁文件的 Bug另外开 Commit或者另外开 PR。3. 精通你的 Git 本地历史重构Ben Deane 在演讲中提到如果你用 Git 却不修改本地提交历史那你其实没发挥出 Git 的真正威力。优秀的代码作者其本地提交历史在开发时可能是混乱的但在推送到远端之前一定会经过精心的“修剪”。善用工具熟练使用git add -p/git add -i来交互式暂存代码以及git rebase -i来合并squash、拆分split或重排你的本地 Commit。不要只写单行 Commit 信息好的 Commit 信息应该清晰交代三个问题你修复/添加了什么你选择了什么解决方案为什么这么做这是最核心的 context4. 编写不可妥协的、精简的测试测试是审查者的第一道防线。有时候审查者甚至会先从看你的测试代码开始以此来理解你的业务边界。拒绝臃肿如果你的一个测试需要 20 行的 Mock 模板代码Boilerplate才能换来一个断言Assertion那说明测试设计得不够清晰。铁律如果你是在修复一个 Bug必须包含一个能稳定复现该 Bug 的测试用例。这是不可妥协的Not negotiable。5. 主动出击在自己的 PR 上写“导游词”PR 提交后不要干等着。你可以成为自己代码的“导游”。在现实开发中由于时间或技术限制我们难免会在代码里做一些妥协Compromise。与其等着审查者揪出来盘问不如主动说明。行动点在提交 PR 后自己先浏览一遍代码在有疑虑、复杂、或者做了折中的地方自己给自己留评论“注意这里因为系统 A 的限制我做了这样的处理未来可以如何优化……”引入规范推荐团队采用Conventional Comments规范在评论前加上[task]、[suggestion]或[question]明确球在谁的脚下。结语想要高效先学会 reciprocate互惠最后Ben Deane 提到了一个非常朴素的道理如果你希望别人能及时、高质量地帮你审查代码你也必须为他人付出。把代码审查变成你每日工作流的一部分。每天早上开启工作时先从你的 Notifications 标签页开始帮团队成员看几个 PR。当你营造了这种高效互助的团队文化你自己的 PR 合并速度自然也会起飞。你对代码审查有什么心得或者深恶痛绝的痛点吗欢迎在评论区留言讨论
