多久一次Code Review才是合适的？

多久一次Code Review才是合适的？这是这段时间一直萦绕在我心里的一个问题。

从前做过一个项目，组长每天都会花一些时间来做Code Review，然后会在第二天通过邮件告知我们，哪些地方做得不对，哪些地方做得不好，哪些地方做得还不错。另外如果需要增加或者修改什么功能，都需要通过邮件通知项目组中所有的人，虽然有设计人员编写的Spec，但是多数情况下，还是以邮件中的表述为准，主要原因是在那个项目中，Spec相当于概要设计，而邮件相当于详细设计和讨论版。

另外一个我参与的项目则是很少做Code Review，或者是在一个项目周期行将结束时做Code Review。当然，这个Code Review的学习交流成分居多。不过鄙人私下认为，这种做法有毕其功于一役的嫌疑，对项目的正面推动作用有限。

那么这里就有一个问题，就是为什么要做Code Review。鄙人私下认为有如下好处：

1. Pulse Check

2. 及早发现问题，并调集资源解决问题

3. 创建一个融洽的沟通氛围和习惯，利于团队成长

因此个人认为，项目不忙的时候一个星期一次比较合适，项目紧张的时候一个星期两次比较合适，毕竟越是紧张，越是要小心行事。检查的主要内容如下：

1. 从上次Code Review到现在所有人提交的Change List

2. 各个组员负责的模块的进度是否同步

3. 各个组员目前遇到的问题

4. 将来可能遇到的问题

在下发这篇文章更多的是想进行一次调查，看看社区中的各位同仁是如何看到这个问题的，希望各位不吝赐教。

在此谢过！