加餐三 | 聊一聊Google是如何做Code Review的

国内code review难推广的一个原因可能也和文化有关，老外习惯直来直往评价和就事论事，中国人为人处世讲究委婉，要面子，特别同级别同事间往往不好意思直接指出别人的问题

之前好像听池老师说过：极客时间团队是有Code Review的。 感觉这件事主要还是看团队吧。

公司让我等制定code review规范，并推广。 ps:现在公司情况：code review 各自（组）为政。 我了解的几个组是只在乎功能正确性，不怎么在乎编码规范/风格、命名风格。各组的评审流程也不一样。 我现在的思路 1、收集各组的评审方式及规范 2、整合各组的方式和规范结合业界的最佳实践（如google）制定出适合我司的一套规范与流程1.0 3、推广使用，收集反馈，补充和优化规范和流程，避免形式化 小争哥或各位学友有哪些好的建议呢，谢谢

有时候review同事的pr，一些语法和编程风格的问题比较多，好像重视程度也不够，反馈后新的pr仍然如此，对reviewer来说就不太友好了，觉得我提的问题太傻了么？

感觉还是没有会 Code Review 的人带

想了解下Google是如何将这些规范落地的？有什么具体措施国内公司能够借鉴吗？道理大家都懂，但实际操作起来怎么监督实施呢？

老师，我看了google的code review最佳实践，发现是以每一次的pull request为维度进行的code review，而我们现在的code review是以项目为维度的，项目提测前进行统一的code review，发现不好的代码，leader让去修改，这样两种方式哪种更好点啊

原因： 1.缺少追求卓越的氛围。先run的理念退化成了能run就行。 2.招聘要求上基本都会有代码设计能力，编码规范，甚至代码洁癖的项。但实际上基本不提，顶多背几个设计模式。那么编码能力就变得很鸡肋，因为它与薪资几乎无关。叫好不叫坐大概就是这个意思。 3.重构本是小步快跑，但我看到的大部分都是重写，而非重构。这就导致认知中的重构成本很高，进而就会排斥。而只写代码不重构代码，在编码能力的提升上是很缓慢的。如果把识别坏代码的能力看作是一把尺子。经常重构的人，这把尺子的精度是一毫米，只写功能的人精度只有一分米。那么在识别坏味道评估改动点时就会很模糊，模糊就更不敢下手，恶性循环。 办法： 1.氛围，国内的开源项目先开始讲究，带个氛围。 2.将编码能力和算法放在同等位置看待。其实编码能力强的人，往往意味着思路清晰，讲究。这种人工作能力一般差不了。 3.普及重构理应小步快跑的理念。把事情拆小，把小事情做好，都很重要。重构需要会拆解工作，然后也别看重构手法简单，刻意训练后也会有质变。（重构是提高普遍认知的有效手段，只有认知上去了codereview才能被 重视）

我同时在美资外企和中国本土企业工作过，看到了另一个方面的问题：在美资企业，往往技术领导者有很大的权限，甚至很多公司的最高领导自己就是技术出身，对技术非常重视，也重视代码质量。 而中国的本土企业，大部分公司的领导都是销售，财务出身，有些甚至来自投行，把PPT看得重于一切，至于代码质量，抱歉，领导可能重来不知道代码还有质量这回事，不是应该完成功能通过测试就OK了吗？ 而且，大部分的项目都很短命，就像中国的PPT文化一样，开发项目的目的就是“骗骗你”，钱到手了，项目的是否易于维护，是否易于扩展都并不重要，领导不关心，抱歉，你还真以为你要做一个Facebook呢？看看中国有几个BAT就知道了。

就个人的工作经历来看，很多互联网公司程序员的职责就是完成业务，没有功能bug是第一位的需求，至于代码质量，在leader的眼中根本就不重要。而且一个需求提出之后，恨不得马上就能看到结果，发布上线。在这样的大环境之下，996盛行，code review就被认为是浪费时间，怎么能推行的开呢？