为何要坚持code review

我的经历

首先聊聊我code review的经历，当时刚刚来到百度，负责FE这边的高T是从Google过来的，据说他将不少Google那边的风格复制到了百度，其中code review就是重要的一块。

code review在我入职时，能够说是严格到使人发指，代码不经过没法提交，并且常常占用整个开发时间的大约40%。我当时的一段代码能够说常常被打回来5，6次。有时最终提交的代码都直接重构了当初的初版。我也曾经由于code review，好几回差点耽误了开发进度。。

而如今我常常做为审核人员去review其余同窗的代码，有时就感慨，因为项目的压力，如今没有之前那么严格的，可是code review我仍是认为须要坚持下去的。

此外据我了解，即便在百度内部强制了code 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即不用浪费不少时间，并且问题都能快速暴露，快速修复。代码始终都能在保证在一个正确的方向上。

博客地址

http://tangguangyao.github.io/

微信微信公众号