【外评】代码审查反模式

为了写这篇文章，我已经收集了很多年的笔记，这些笔记来自我参与过的代码评审（双方）、我观察过的其他人之间的代码评审以及我只在谈话中听说过的代码评审。

【外评】代码审查确实能发现漏洞

微软论文的主要论点似乎是，代码审查不值得花费时间。我们已经看到，如果审查工作量管理得当，代码审查在发现缺陷和学习代码库方面都非常有效。

幽默视频：给新来的程序员写的代码做审查

总感觉有什么地方不对劲！

做了 1000 次 Code Review，我学到 3 点经验

当我在 LinkedIn 工作时，工作的很大一部分内容是做 Code Review。在这个过程中，我发现一些人很容易犯的错误，于是把它们整理起来并分享给团队。

如何让代码审查更具人性？

最近，我一直在读有关代码审查最佳范例的文章。我注意到这些文章的关注点是找到 bug，而忽略了代码审查其他的部分。用建设性、专业的问题沟通方式？不相关！只要识别出所有的 bug，剩下的部分会水到渠成。

现实中的代码评审

我本人特别反对一种颇为常见的观点，就是“一个良好运作的项目，不同的人，应该写出一样的代码”。我非常理解这种观点的初衷，一个良好规范约束的团队中，不同的人写出来的代码应当一致。

Code Review, 有用吗？

或许应该说，Code Review, 达到了它的目的了吗？

比尔·盖茨评审产品时说 F**k 最少的一次

本文作者是 StackOverflow 联合创始人、知名博主 Joel Spolsky。本文讲述他于 1991 年在微软做 Excel 的 Program Manager 的时候，与 Bill Gates 一起 review 产品的感受，行文生动有趣。另外，微软鼎盛时期的 Program Manager ，技术能力很强的。

京东资深架构师代码评审才诗

架构师说, 用20个字描述代码评审的内容， 自省也省人。由于是一字一含义， 不连贯， 为了增强趣味性， 每句都增加对应的歪解。只是对常见评审的描述， 不尽之处，欢迎补充！

如何做有效的代码审查？我有这些建议

往往代码评审过程中，评审者（Reviewer）往往会过于关心旁枝末节，而忽视主要问题，也就是所谓的自行车棚效应。在批准价值百亿的核电站的建设提案中，专家们往往会浪费大量时间纠结于厂内自行车棚（bikeshed）的颜色；因为核电站太大、太复杂，“专家们”未必真懂，但总不能不说话啊，那就从无关痛痒的自行车棚挑毛病吧。

代码审查与重构的5个层次

统一的代码风格规范是团队开发的重要要素之一。代码规范的统一有利于代码的阅读维护，有利于代码的“集体所有制”。试想，如果团队中每个人都使用自己的一套代码规范，那整体的代码风格就可谓“百花争放”，最后的结果就是代码越来越混乱，且难以阅读维护。我们项目中统一的代码风格概括来讲有如下几个方面：

十个有关代码审查和质量的事实

45％ 的开发人员说，“缺少时间”是审查代码的真正障碍，而 34％ 的开发人员则认为是迫于“发布新功能的压力”

什么才是Code Review的正确姿势？

硅谷稍具规模的公司 code review 的流程都是比较规范的。模式也差不多。一来所有的 PR 都必须有至少一个人 stamp，才能 merge。如果改的东西涉及到多个项目，则需要每个项目都有人 stamp 才行。还有一些特别关键的代码，

代码审查要点

给别人的代码做 Review 的人(Reviewer), 他的责任不仅在于保证代码质量, 更重要地是承担拼盘者角色. Reviewer 必须为自己着想, 认真负责地进行代码 Review, 以免日后自己接手一个逻辑不通, 代码混乱的项目(程序员俗话说的”一坨屎”).

代码审查的5点经验教训总结

我们时常会听到团队成员说：

“这个项目搞代码审查简直是在浪费时间。”

“我没时间做代码审查。”

“发布会延迟，是因为我那个卑鄙的同事还没有审查过我的代码。”

“你能相信我的同事居然要求我改我的代码吗？我这么优雅完美的代码哪里还需要改呢。”

代码审查的重要性

　前些天有人写了一篇超精彩的博客贴子，是关于之所以要将优秀的程序员从平庸的群体中挑选出来的重要性。这篇文章写得真的很好，因为它讲述的情况和产生的可怕后果，在我的职业生涯中我已经见得太多太多了，不过这其实是很容易阻止的。