标签： 代码审查
每5个人中会有4个很享受代码审查
每5个人中会有4个很享受代码审查
【外评】代码审查反模式
为了写这篇文章，我已经收集了很多年的笔记，这些笔记来自我参与过的代码评审（双方）、我观察过的其他人之间的代码评审以及我只在谈话中听说过的代码评审。
【外评】代码审查确实能发现漏洞
微软论文的主要论点似乎是，代码审查不值得花费时间。我们已经看到，如果审查工作量管理得当，代码审查在发现缺陷和学习代码库方面都非常有效。
【译文】代码审查中我忽略的 3 件大事
汤婆婆给千寻改了个名：从“千寻”改为“千”。一旦失去了原本的名字，人们便失去了逃离浴场所在的异世界的能力，甘心永世被汤婆婆所奴役。
马斯克凌晨一点半晒“代码审查”现场 编排他的段子比疯狂星期四还多
每一个真正会写代码的人，请在下午2点到总部10层报到。马斯克在周五向推特工程团队（或者说剩下的部分）发出召集令。他要求工程师们来之前总结6个月内的工作要点，连同10张最有代表性的代码
给初创公司审核代码 5 年，我总结了这十几条经验
给初创公司审核代码5年，我总结了这十几条经验我在PKC公司工作时，做过20多次代码审查，其中许多客户是刚刚获得A轮或B轮融资的初创公司。他们这个
给初创公司审核代码5年，我总结了这十几条经验
作者 | Ken Kantzer 译者 | 叙缘 策划 | 凌敏 我在 PKC 公司工作时，做过 20 多次代 […]
幽默视频：给新来的程序员写的代码做审查
总感觉有什么地方不对劲！
做了 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％ 的开发人员则认为是迫于“发布新功能的压力”
没有代码审查和测试驱动的经济成本和时间成本
近些年来，越来越多的人开始向我咨询测试驱动开发（TDD）的好处。所谓TDD，就是在将代码进行部署之前，利用各种自动化测试来确保代码能够正常工作。在进行测试的时候，你需要寻找测试失败的地方，然后不断修改，必要的时候还需要对代码进行重写。实践证明，TDD是软件开发过程中必不可少的一环。而且它还能够帮助企业和员工节省大量的时间。
C语言代码评审小结
在实际的软件开发项目中，代码评审是一个必不可少的流程。代码评审，也称之为代码复查，是指通过阅读开发人员所写的代码来检查源代码与编码规范的符合性以及代码质量的活动。总的说来，代码评审的好处有以下几点
什么才是Code Review的正确姿势？
硅谷稍具规模的公司 code review 的流程都是比较规范的。模式也差不多。一来所有的 PR 都必须有至少一个人 stamp，才能 merge。如果改的东西涉及到多个项目，则需要每个项目都有人 stamp 才行。还有一些特别关键的代码，
代码审查要点
给别人的代码做 Review 的人(Reviewer), 他的责任不仅在于保证代码质量, 更重要地是承担拼盘者角色. Reviewer 必须为自己着想, 认真负责地进行代码 Review, 以免日后自己接手一个逻辑不通, 代码混乱的项目(程序员俗话说的”一坨屎”).
不做代码审查会怎样？
在真正的实施过程中，很多情况下并不像想象的那般美好，经常出现例如有些同学由于跟不上其他人讲解的速度（毕竟不是自己写的）或是没有相关的上下文（例如刚加入项目的新成员），或是由于提交没有被很好的切分和组织，导致整个过程都处于游离状态（就像下图中的我……毫无摆拍痕迹），而代码审查的效果也打了折扣，渐渐的变成了一个流程，一个过场， 一个习惯。
代码审查“查”什么？
让我们来谈谈代码审查（Code Review）。如果花几秒钟去搜索有关内容，你会发现许多论述代码审查好处的文章（例如，Jeff Atwood的这篇文章）。你还会发现许多介绍如何使用代码审查工具的文档，比如我们常用的Upsource。但能够在你审查他人代码时指导查什么的内容却很少见。
代码审查的5点经验教训总结
我们时常会听到团队成员说：
“这个项目搞代码审查简直是在浪费时间。”
“我没时间做代码审查。”
“发布会延迟，是因为我那个卑鄙的同事还没有审查过我的代码。”
“你能相信我的同事居然要求我改我的代码吗？我这么优雅完美的代码哪里还需要改呢。”
代码审查的重要性
前些天有人写了一篇超精彩的博客贴子，是关于之所以要将优秀的程序员从平庸的群体中挑选出来的重要性。这篇文章写得真的很好，因为它讲述的情况和产生的可怕后果，在我的职业生涯中我已经见得太多太多了，不过这其实是很容易阻止的。
