好处：
1、可以通过大家的建议增进代码的质量
2、它是一个传递知识的手段，可以让其他并不熟悉代码的人知道代码的意图和想法，从而可以人人维护代码
3、可以鼓励大家相互学习对方的长处和优点
4、可以用来确认自己的设计和实现是一个清楚的和简单的
原则：
1、经常进行Code Review
- 代码越多，修改的代码就会越多，因此越不会被程序作者接受的建议也会越多
- 越接近版本发布的最终期限，代码就不能改的太多
2、Code Review不要太正式，而且要短
3、尽可能让不同的人Review你的代码，但不要超过三个人
- 从不同的方向评审代码总是好的
- 会有更多的人帮你在日后维护你的代码
- 这也是一个增加团队凝聚力的方法
4、保持积极的正面的态度
- 对于代码作者，需要能够虚心接受别人的建议，因为别人的建议是为了让你做的更好。
- 对于评审者，需要以一种积极的正面的态度向作者提意见，因为那是和你在一个战壕里的战友。
5、学会享受Code Review
当你所在的团队人人都喜欢Code Review，那么你所在的团队必将生机勃勃，每人都可以写出质量非常好的代码，甚至不需要经理的管理，团队会自适应一切变化，他们相互学习相互帮助，不仅仅是写出好的代码，而且团队和其中的每个人都会自动进化，最关键的是，这个是一个团队。
必要的审查清单：
是否有多余或者重复代码
代码是否简单易懂
是否有被注释掉的代码
函数 / 方法 / 调用接口是否都有注释
是否遵循规范（CSS规范，提交代码规范，...）
代码是否尽可能的模块化
代码的设计是否合理易扩展
。。。（内部再讨论其余的）
实行
1、采取怎样的方式？
2、多长时间review一次？
3、激励机制？
4、什么样的代码拿出来审查？（比如：写了公共方法组件、页面重构、新页面等等）
5、针对复杂问题或者自己没有把握的问题，可以写一个简单的设计文档，表达自己的设计思路，然后做一个设计的审查，以提早发现问题，或者根据建议采取更好的实现方式，以提高开发效率。
6、前端成员轮流组织代码审查，组织者针对每次审查发现的问题整理出文档，必要时进行分享。（有过程有记录）
抛砖引玉
时间：每周周五5点开始到6点半
方式：在小会议室通过一个半小时的时间Review三个人的代码，平均每人半小时左右，互相检查学习更正（检查内容参考上面的审查清单）
激励：每次出现问题最少的和指出问题最多的两人给予奖励（奖励待定）
记录：组织者进行每次记录，必要时作分享