我觉得很幸运的是我的第一份工作所处的团队就严格执行了Code Review。从刚开始别人替我Review到现在我为别人Review，不管是Review这个过程本身，还是角色的转变都带给我很多收获。

Code Review能给被Review的人带来什么？

在校时，我曾经在一个小公司实习过，全公司只有两个前端，工作过程中只要能实现效果就行，从来没有Code Review这个说法。

毕业之后，来到美团，每一个Task做完之后都有严格的提PR、做Code Review的流程，幸运的是组长在Code Review 方面非常认真负责，不仅仅是代码结构等大的问题，很多小的问题都会指出来，比如：变量名没有取好，没有注释等。

刚开始是很不适应的，不仅仅是因为你花了很多时间写好的代码拿到别人那里看时被指出这里有问题，那里有问题，有时你甚至会觉得很烦。而且你在写代码时在头脑中就会有一些念头：等会是要Review的，这个命名是不是够好？这个有没有什么逻辑问题？这里还是加个注释吧。

时间长了之后，Code Review的作用就显现出来了，很多Review过程中被指出来的问题，自己在写代码时就会习惯性的多注意，虽然初衷是不想被Review的人吐槽，但实际的效果却是让你培养了很多好习惯。

Code Review能给Review的人带来什么？

1.类似问题的不同处理方式

同一个职位的人在工作中遇到的问题很多都是类似的，比如前端，通常会遇到不同OS、不同浏览器下的兼容性问题，这个时候去Review别人的代码，你会看到别人在遇到这个问题时是怎么解决的。是不是和你之前处理这个问题的思路相同？你们俩的思路哪个更好？这样一个过程对自己是收益良多的。

2.促进自己培养好习惯

在Review别人的代码时，你会主要关注哪些方面呢？就我自己的经验来看，Review的人是很难在Review的这段时间里去理解你项目的业务逻辑的，特别是当你的项目比较复杂的时候，别人能关注的主要是一些函数的用法（用法是不是有什么问题），一些通用的功能（下拉加载、防止二次提交等），变量命名是不是有什么问题，是不是写了详细的注释等。关于业务逻辑只能是靠自己把握（测试主要就是测试业务逻辑，因此除了你需要在代码层面好好把握，测试也是发现业务逻辑bug的时候，所以你不是一个人 ~ ）。

当你给别人指出一些问题时，你自己在写的时候就会自然而然的更加关注这些方面。要是自己都做不到的话就去吐槽别人，你心里也不好意思吧 ~

总而言之，Code Review是一件对Review双方都非常有益的事情，所以，看到这篇文章的你如果团队里有Code Review的流程，一定要好好利用，如果没有Review的话，争取推行吧，这样你也能成为团队里的Review第一人了 ~

END