一个项目，由于同时需要完成的需求会比较多，需要多人协作，而团队成员每个人工作习惯和技术水平都有差异，所以最终提交的代码会有各种各样的风格，同时也存在各种潜在的问题，所以在代码合入主库前，会有一个代码review的过程，来提前发现这些问题。同时为了能够统一代码的风格，我们也会制定一些统一的代码规则，这些规则也需要一定手段去保证每个人去遵守，这些手段主要一个是代码静态检查，另外一个就是平时代码review时去督促大家按照规则来写代码。
一般代码的review是由项目的负责人处理，或者类似与项目开发主管的角色来做。
如果review的人一直处于一线开发，是可以发现代码里面的业务逻辑问题，如果长期脱离一线开发，那只能发现一些代码逻辑问题和一些基本的规范问题，并不能发现业务逻辑上有什么问题，这个可能需要测试去发现这个问题。
代码的review一般主是为了以下几个目的：
- 提交的代码符合项目组制定的规范
- 代码中没有明显的bug
- 风险评估，如果修改涉及到多个模块，那么风险会比较大
- 保证核心功能不被破坏，一些核心代码是不应该允许随意修改的
- 了解项目的进度
- 从整体的角度去分析项目模块结构是否有可以优化的地方
首先如果只让一个人去review所有人的代码，这个是很难达到预期的效果的，一是随着代码量的增长，一个人很难了解所有的业务逻辑的；二是每个人的状态是不停在变化的，所以仅依靠一个人是很难保证稳定的review效果；三是每个人都有可能请假或工作变动，必须需要安排备份。我们在项目中，一个是每个模块都划分对应的负责人，每当你修改了一个模块的代码，review时就必须把这个模块的负责人给勾上，这样每个人在修改自己不熟的代码时，至少会有两个人参与review。有的时候你特别忙，而测试有特别急着回归bug，有另一个人帮你把下关，你也可以稍微不那么仔细深入的看，可以把时间用在更紧急的事情上，这种情况也是经常会发生的事。另外在每次发布上线前一天，我们会集体review评审，每个人把自己修改的代码通过投影，让大家一起看，你需要简单的讲下你的代码的目的，大家一边看你修改的代码，一边看代码是否有bug，是否实现你期望的目的，这样就进一步降低了代码出现bug的概率，同时你知道了代码会拿出来供大家评审，那么在写代码时也会更加谨慎一些。
在上一家公司，部门制定了规则，每周四下午是集体相互review代码，同时也制定了相应的激励和惩罚措施，每个人平均的review意见不能少于5条，每月统计各个项目组总的代码review比率，比率最低的项目组支付给代码review参与率最高的项目组100元，作为活动经费。这个在一定程度上，提高了大家参与代码review的热情，同时也对改善代码质量起到了一定的作用。