我所供职的公司的小组采用了非常严格的code review制度，这主要是manager的要求。code review是件好事情，但是至少我在公司的经历而言，绝对是噩梦一般的体验。毫不夸张的说，某个简单的需求，我用了半天实现了，但是要合并到主分支，最少需要三到四天左右的时间，注意这仅仅是简单的需求，有的代码merge周期甚至超过两周，听起来非常不可思议。
我的观点是：code review和能写出更好的代码关系不大，可以一定程度上避免写出糟糕的代码，但不能保证代码质量。对于正规的项目，code review是必不可少的，但是过度依赖和相信这个能解决质量问题是不可取的。
错觉之一：code review 可以保证代码质量。 你根本无法保证你的reviewer们好好看代码。code review不能保证质量，测试才能保证。从我的工作上看，大部分review comment只能看到表面问题，这些只能使得代码更完善，避免一些低级错误，但和代码优不优秀根本是没有关系的。如果一个项目的设计有一些地方从根本上就是有问题的，那么无论代码表面上看起来是多么规整，质量也是糟糕的。代码质量是优秀的架构设计所保证的，在一个设计糟糕的系统中添加新的模块，和在一个设计精良的系统中添加新的模块，其开发成本是差异悬殊的。设计糟糕的系统，功能的开发者，需要考虑的事情会更多，写的需要更多，和别的模块造成的耦合也会更多。新的这些代码写出来，即便是别人精心review过，也并不可靠，更不要说别人也没有仔细看了。
通过code review 来妄想质量上的完全是可笑的。在工程化的角度而言，只有机器是不会犯错的，人是会犯错的， reviewer是人，你能指望人不会搞砸事情吗？我们应该相信机器，所以应该是测试，自动化的，可靠的测试，来保证质量。code review了，包发出去了，下游炸了，reviewer要跟着一起背锅了。于是乎，事情变成检讨为什么制度上失效，而不从整个代码库糟糕的设计上找原因。于是乎以后大家花更多时间review code，写完自己review一遍，别人review一遍，master review一遍，谁都要自己亲手花个半小时把下游环境构建出来，手工的调，手工的测。甚至很多时候就是手工的看一看有没有regression。时间全都浪费在这些地方上了。你说一个项目，写的渣也就算了，没有完备的自动化测试，反而以code review的形式，让大家画非常多的时间手工测试来保证正确性，来说code review能保证工程质量，这。。。
虽然有些review这个过程并不是非常耗时，不过当你正在做一个东西，然后别人突然给你assign一个review，你不可能立刻停下来去看的，然后他只能去做其他的任务，等你看完让他改了，他也不可能立刻改的，也得先把手头事情做完。所以有很多上下文切换的成本。这些就导致开发体验很糟，更不要说，我并不是很认可团队上对code review的认知和实践，很不爽。
当你在一个项目中进行开发，merge到master的成本很高，这对contributor的积极性是很大的打击，潜在的，阻止了一些优秀的实现和设计。优秀的设计往往需要作出颠覆性的假设和修改，推进不成熟的设计到成熟需要时间，说服别人需要时间甚至技巧，这些隐形成本都很高昂。不说优秀的设计，即便是小的改进，如果流程繁碎，那如果开发者并不是很关心项目，那也会放弃去做这件事情，毕竟这不是分内之事只是好心。当我看到某段代码不是很好，想要改动，但是一想到后面几天我都要follow这件事情，又不是很重要的逻辑，那就索性放弃了，久而久之当大家都被这种意识所影响的时候，那code review反过来加速了软件工程项目的腐朽。
更为让人不爽的事情，是仓库的owner其实不熟悉代码，你既然不熟悉代码，我还要给你解释已有的细节，那你凭什么能知道我的代码的好，又怎么才能看出代码的坏？即便是要负责，也应该是有资格的人负责，从某种意义上讲，一个没有资格review的reviewer，强行review，强行控制节奏，是可怕的事情。
要论code review的好处，我已经听了太多话，看了太多文，但工作上给我的体验真的非常不愉快，好处有限，性价比超低。这主要是错误的实践方式造成的，错在大幅牺牲效率，用人代替机器保证质量，用review代替测试保证质量，错在一味的走流程，错在仓库owner对项目的掌控太弱，本身理解不足，这些使得code review在实践之中存在带来的巨大沟通成本和执行成本，带来的好处不足以值得付出这样的代价。
如果我自己开公司，或者说自己负责技术。review是需要的，但至少这样几点来保证review效率：
1 针对项目而言， 只有contribute最多的人才有资格own项目，才有资格拥有merge权利，才有资格主导review流程。
2 在合作做项目的时候，每个人清楚的负责好自己的模块，划清责任界限，如果一个地方由多人负责，就不会有人负责，代码质量的责任完全在开发者身上，而不是让混乱和走形式的review强行分锅。
3 产品以自动化的测试这一唯一方式来保证质量。
这些大概就是目前我对code review的一些经验和想法。
