作为开发者，我们写好代码、点下 “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 信息应该清晰交代三个问题：

1. 你修复/添加了什么？
2. 你选择了什么解决方案？
3. 为什么这么做？（这是最核心的 context）

4. 编写不可妥协的、精简的测试

测试是审查者的第一道防线。有时候，审查者甚至会先从看你的测试代码开始，以此来理解你的业务边界。

• 拒绝臃肿：如果你的一个测试需要 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 合并速度自然也会起飞。

你对代码审查有什么心得或者深恶痛绝的痛点吗？欢迎在评论区留言讨论！