标签归档：代码审查

本文作者是 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, 以免日后自己接手一个逻辑不通, 代码混乱的项目(程序员俗话说的”一坨屎”).

不做代码审查会怎样？

在真正的实施过程中，很多情况下并不像想象的那般美好，经常出现例如有些同学由于跟不上其他人讲解的速度（毕竟不是自己写的）或是没有相关的上下文（例如刚加入项目的新成员），或是由于提交没有被很好的切分和组织，导致整个过程都处于游离状态（就像下图中的我……毫无摆拍痕迹），而代码审查的效果也打了折扣，渐渐的变成了一个流程，一个过场，一个习惯。