我们也有代码审核，但是我认为很失败，主要表现在形同虚设。
原因如下:
1.领导分配任务时，没有给评审分配时间。在相同的时间内，在原有工作量之上在加入代码评审，评审就是负担，应付了事；再说代码评审有没有奖惩。不看代码，接先approval然后merge就成了最常见的做法。
2.pr看不懂
    a.pr说明描述不清或者没有描述。
    b.pr里面包含很多东西。
3.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核心路径的单元测试。这一步其实目前我们还没有，但我觉得是有必要的，正在计划推动落地。