32 | 硅谷人如何做 Code Review

写蛮棒的，我比较喜欢文中的观点: 1) 代码审查可以让工作可扩展; 2) 审查边界情况; 3) 代码回滚的例子; 4) 那段Ruby代码的考虑点问题; 5)有ui改动相关的，要给改动前和改动后的对比图(这点我一直在做，也在要求别人做 😁) 此外，从我经验上，还有这么几点: 1) 持续集成环境可以跑测试，测试结果可以自动加到PR上面(我觉得你们肯定是有在这么做的 😁)。这样子让review的人有个更好的信心 2) 代码在build的过程中，可以加上linter，进行code style的检查(我觉得这个你们肯定也在做 😁)。持续集成环境可以把检查结果加在PR上面。我们公司在用code climate的Chrome plugin，这样子做code review的人就不需要提style相关的改动了:能让机器做的事，就没必要让人来做 3) 如果希望强制互相的代码审查，可以在github里面设置，比如master branch，是protected branch，只有在ci通过，有人approve了这个pull request之后才允许merge 4) 在pull request本身要给足context信息，从而让进行review的人很容易搞清楚这个pr在做什么;在之后希望溯源什么改动的时候，在定位到这个pr时，也可以更好地了解当时做这个改动的原因。

我是做Android开发的，负责的是公司Android APP内的一个模块，整个APP是插件化的架构，即APP本身所在项目是一个空壳，通过配置来决定哪些模块会集成进APP。我们这边的做法是： Step 0. Push检查：在每次push之前，检查提交者是否已经自测过了自己修改代码相关的全部分支，并会生成一个自测覆盖率，提交到commit信息中。如果自测覆盖率过低，reviewee需要给出合理原因解释。 Step 1. Merge检查：在提交PR前，先进行代码静态检查，比如lint检查、组里资深工程师根据业务制定的“坏味道”检查等，这样可以避免绝大部分低级错误和常见的共性错误。 Step 2. 人工review，reviewer会指定一个资深同学和一个新人，资深同学把关，新人学习和了解其他同学coding的思路。同时也鼓励新人提出自己的见解，进行思想碰撞。reviewee是新人的话，reviewer会更加注重实现细节，会讨论和比较其他的实现方式；是资深同学的话，会更加侧重在整体架构设计上。 Step 3. 代码合入后，会走一个自动化的打包和集成工作。打包后会集成进APP，这个过程会在APP范围内进行全局检查，确保没有底层项目接口变更导致上层项目接口调用失败的问题。 Step 4. 集成后形成一个apk，然后跑自己业务以及整个APP核心路径的单元测试。这一步其实目前我们还没有，但我觉得是有必要的，正在计划推动落地。

我们也有代码审核，但是我认为很失败，主要表现在形同虚设。 原因如下: 1.领导分配任务时，没有给评审分配时间。在相同的时间内，在原有工作量之上在加入代码评审，评审就是负担，应付了事；再说代码评审有没有奖惩。不看代码，接先approval然后merge就成了最常见的做法。 2.pr看不懂 a.pr说明描述不清或者没有描述。 b.pr里面包含很多东西。 3.pr不给留时间，或者留时间了也没有人看。

首先是招聘到合适的人；其次如果人不行，怎么推进点东西都费劲的；我们这我推进的代码审核，好似把他们打劫了一番，好比老牛不喝水推上刑场一般

很庆幸之前的团队就是这么做的，开始觉得太苛刻，后面慢慢觉得这样对大家(特别是对自己)的成长挺大的。后面我在review别人的代码的时候也“苛刻”了些😬

我想有人来review我的代码，但大哥们都忙。

工作时间没时间做review

真的挺希望能加入一家有这样环境的公司，然而我呆过的大小厂都没有这个

在国内公司，Code review如何能不流于形式还是个挺有挑战性的问题

代码review不太好执行，国人比较爱面子，我一般的做法是，线下反馈review建议。