review的目的

有和没有之间的态度差别
很简单，一段代码完成之后，有人看和没有人看，在质量上还是会有差别的。
当你知道你的代码会被人一行一行review时，你的代码一定为努力写的最好，而不是为了完成功能而应付了事，这就是态度上的区分。因为当你知道你写的代码是有人看的，你会更加在意你写的东西，你一定不想背后被人说，代码写的像一坨**。
而且确实我自己在review代码时，就能看出哪些为了赶上线而写的就和平常写的会有差别。

什么是代码review？

其实就是代码再次查看评审。

什么时间该去Review？

在我们每一个小的版本迭代完后，就去Review代码。

怎样对代码进行Review？

下面是每次提交代码之前，可以参考的一份Review代码的清单，事实证明这样做可以提高代码的质量和功能的稳定性。

代码的可读，可维护

代码的可读和可维护在大团队很关键，最初我们代码审核为什么严格到令人发指，就是因为可读性和可维护性。
严格的code review可以感觉整个团队写出的代码就像是一个人写的。这样就是为了能让你随时切换到其他业务上，而且不需要什么适应时间。
可读性和可维护对于大型的多人合作系统，可以说非常关键，当一个团队30多人在一个单页面开发时，如果风格各异，代码仅仅符合功能和测试要求的话，你会发现多人开发的成本和新需求的升级的成本会越来越高。

举个常见的例子：

如果某个业务突然需要提高进度，这时的办法就是加人力，但是如果代码风格各异，加入的人力适应时间和学习成本是极高的，有时甚至不如保持原有人力去加班hold。要不就只能找些技术很强，可以无障碍学习的资深工程师江湖救急。

我们这边其实就是会出现上面项目突然加急的情况，但是，因为有code review，所以我们多人合作时，基本上可以保证1+1≈2的效率。为什么这么任性，就是因为在code review时已经控制了大家的写法和模式，让新加入的同学能够马上看懂以前逻辑并且做大概的业务了解就能上手了。
我这边最近就经历了这些，因为需要还一些历史遗留的技术债务，所以我需要调整底层的一些代码结构，这时保证功能和互相调用ok的情况下切换代码位置和路径就是我遇到的最大的障碍。
不过由于之前业务代码的高质量和开发模式基本上完全一致，所以我能很快找到统一的切入点，预先就能预估好可能会踩的坑。
如果没有code review之前严格的约束，我基本上需要每个业务功能去分析了，效率降到极低。

对于新人，快速引导，快速反馈

对于新人加入我们的团队，最快的上手方式就是，简单熟悉完之后，接手一个业务项目，然后我们会通过不断的code review给与开发方式，编码习惯，设计模式之间的反馈。
第一个项目的review 基本上会是最严格的。
其实对于技术人员，code review 就是用代码在做沟通。

及时发现非代码上的问题

有时我在review代码时会发现，有些地方经常在反复修改，或者有时实现会非常别扭。这时我就会问开发人员，是不是需求不明确导致的，是不是对需求的理由有偏差。
因为对于正在开发的同学，经常会陷入到业务具体的实现中，有时就是饶了很大的圈子但是自己确不知道。这时review时是能感觉到的，而且我也成功的多次阻止过。

对于效率的影响

很很多团队拒绝code review 主要是基于时间不允许，项目追的太紧之类的。
不过因为我也经历过没有code review的开发方式，我的感受是code review的影响不会有大家想的那么严重。

这里关键是具体如何去做

举例：

在开发一个新模块时，由于对于业务的开发模式不熟悉，上来就直接把功能什么的，需求什么的都搞定了。洋洋洒洒几千行代码的产出。最后需要提交时，review的人发现，我靠。。。这种实现不是我需要的，以后会埋很多坑啊。这时怎么办，重构？时间够吗，还是就这样了，把坑留给二期？

我们要求的code review不是上面那种，我们要求每次提交的内容尽量少，完成一个小的功能点就可以提交。这样review的人看起来也会越快，反馈的时间也会约迅速。
例如，完成目录结构和框架就可以提交一版，这时可以review文件名字起的是否合理之类的。
在每次提交代码的时间上，我们也是期望每天都会有提交，最长也不要超过3天，不然最后提交的代码对于review的人也是负担，出现的问题也不一定来得及修复。如果长期这样，确实是会影响到开发效率。

其实合理的code review即不用浪费很多时间，而且问题都能快速暴露，快速修复。代码始终都能在保证在一个正确的方向上。