代码审查心得:二十年实践总结

Published by rcdfrd on 2025-09-15

代码审查心得:二十年实践总结

原文作者:Matthias Endler


做代码审查二十多年了。现在我一半以上的工作时间都花在审代码上,这和系统设计一起,是我最主要的工作。

二十年下来,我对代码审查的看法变了很多。刚入行时关注的东西,现在早就不在意了。


一、先看全局,别只盯着语法

差的代码审查只看语法风格,好的代码审查看的是:

  • 这改动要解决什么问题?

  • 会不会带来新问题?

  • 和整体架构配合得怎么样?

    我喜欢看那些没被改动的代码。开发者经常忘了更新相关模块或文档,这会埋下 bug、破坏兼容性,甚至留下安全漏洞。

    审查时我会想:这段代码在系统里扮演什么角色?跟其他模块怎么配合?会不会影响后续开发?有没有引入更好的抽象?

    这些问题关乎系统设计,不只是代码本身。


二、命名很重要

我花很多时间在命名上。

好名字让代码一目了然,烂名字让人越看越晕。比如这段代码:

fn update_player_stats(player: Player, bonus_points: i32, level_up: bool) -> Player {
    let usr = player.username.trim().to_lowercase();
    let updated_score = player.score + bonus_points;
    let l = if level_up { player.level + 1 } else { player.level };
    let l2 = if l > 100 { 100 } else { l };

    Player { username: usr, score: updated_score, level: l2 }
}

usr、l、l2 是什么鬼?改成这样:

fn update_player_stats(player: Player, bonus_points: i32, level_up: bool) -> Player {
    let username = player.username.trim().to_lowercase();
    let score = player.score + bonus_points;

    let level = if level_up { player.level + 1 } else { player.level };
    let level = if level > 100 { 100 } else { level };

    Player { username, score, level }
}

变量名和字段名一致,一眼就懂。


三、该拒就拒

拒绝别人的代码不容易,毕竟人家花了心思。

但质量不能妥协。说清楚为什么不行,给出替代方案。拒的是代码,不是人。

开源项目尤其需要把关。"先合进去以后再改"——这句话说多了,技术债就堆成山了。


四、审查是人和人的沟通

审代码也是建立信任的过程。

新同事的前几个 PR,我会尽量当面聊或者结对审。先了解对方的风格,建立默契。后面遇到分歧,也好沟通。


五、多轮审查很正常

很多人想着今天提 PR 明天就合。但好代码往往要反复打磨。

我一般这样走:

  1. 第一轮看整体设计

  2. 第二轮看细节和边界情况

  3. 需要的话再微调

    目标不是快,是对。


六、别当杠精

意见不同时,把"你错了"换成"换我的话可能会这样"。

多问问题:

  • "这样会不会破坏现有流程?"

  • "有没有考虑其他方案?"

  • "传个空数组进来会怎样?"

    偶尔夸一句"这个想法不错",对方会更愿意听你的反馈。


七、代码拉下来跑一跑

纸上看代码和实际跑起来是两回事。

UI 改动、错误提示这些用户能看到的东西,本地跑一下往往能发现问题。跑完记下问题,再提评论。


八、忙的时候说一声

审查经常卡住进度。忙的时候提前告诉作者"这几天可能顾不上",别让人家干等。


九、顺便学点新东西

每次审查我都试着学点什么——新语法、新模式、新库,或者别人解决问题的思路。

审代码不是浪费时间,是团队一起成长。


十、格式问题交给工具

空格、换行、缩进,让 linter 和 formatter 去管。

把精力放在逻辑对不对、设计合不合理、以后好不好维护。

问自己:这会影响功能吗?会让后来的人看不懂吗?不会就别纠结。


十一、关注"为什么"

少问"你怎么这么写",多问"你为什么这么改"。

好的评论应该:指出问题、给替代方案、解释原因、附上参考资料。


十二、不懂就问

你不懂的地方,别人可能也不懂。

提问能帮你理解,也能让作者反思设计是否合理。


十三、问问别人觉得你审得怎么样

偶尔问问作者:我是不是太挑剔了?我的反馈有帮助吗?

让别人"审查你的审查",进步最快。


最后

代码审查不只是技术活,也是沟通、学习、建立信任的过程。

做那种让人愿意收到反馈的审查者。


翻译自 Matthias Endler 的博客文章 How To Review Code,有删减。