发个无聊的贴子，看看大家怎么看code review的

我看了大家的讨论，我个人认为大家对于code review的有一些理解是有偏见的。根据我的经验，code review的要求如下：
一、review执行者要求
   1.精通项目组所使用的技术
   2.了解整个系统或者一个模块的业务过程
   3.具有很强的责任感和耐心
二、code review的基本要求
   1.找出不符合项目规范的代码
   2.找出可能在不同的情况下会出现异常的代码
   3.是否是完全符合业务要求
   4.是否对其他的机能造成影响
   以上4点中，后两点是最重要的，但是好多公司和个人往往把1，2点作为重点，也就导致大家认为更本没有必要的想法了。对于业务的检查是没有任何工具能够代替的。

项目早期或新人加入时最初的代码要review，之后抽查就可以

code review
1.code格式和编码规范用工具检查即可，省时省力我用jtest
2.每本代码必须有资深程序员来review，这个review就涉及重构了，它往往能发现一些代码结构的弊病。

3.是否是完全符合业务要求
4.是否对其他的机能造成影响
请问做这两点需要多少时间和精力，什么样的人能很了解业务呢？项目经理还是业务经理？
不仅要了解业务还得精通技术，这样的人好像不好找啊 呵呵

请赐教

我们的QA会来给我们Review的

你这个方法太极端了，我知道一个比较好的例子是降落伞工厂会让生产工人从自己生产的降落伞中抽出样品来试用。

现在程序员能写代码的 一抓一大把 但是会写代码的很少 代码不会写完能运行就是好的代码 reveiw其实是为了保证质量 和减少以后的不必要或者可以避免的工作 reveiw还是应该的 但是怎么reveiw还是看公司大大的要求

如果没有10年的编程经验就不要说Review无用
在我们公司所有文档、代码都必需经过Review，无论何种形式都可以
个人感觉还是比较重要的，findbugs、pmd只能发现一些最基本的问题，逻辑问题它们都搞不定

不过Review要有一个大家认同的标准，文档就是标准模板和业界标准，代码就是编程规范，标准统一了才能发现共性的问题，否则Review之后的结果就是PK……哈哈

pair 个人觉得和code review根本不是相同的用意。pair的人一般是水平相近的人，那么做review进行改进的空间受到了限制，再者，pair的时候两个人是相同的工作内容，code review我觉得重要的用意不单单是检查排版和命名以及某个方法是不是好，更重要的是站在更高一点的高度，整体对代码做review,找出坏味道，减少项目风险，和以后维护的难度，让代码更美，这里要有较多的经验和感觉。所以依赖pmd和check style这种我觉得并不能解决根本问题。

个人觉得如果可能，我说的如果可能，是不是需要演化出专门的review人员，有规定的日程，规定的人员（可以深刻理解重构的人），规定的内容，这样做review才能达到真正的效果。

“所以，我们必须要有统一、稳定的编码规范(format, 目录结构等)”这个我觉得和code review没什么关系，不管是不是需要review，规范还是必须的。

我组织review的目的也是意在3，4条，但是往往真正满足review资格的人少，或准备不充分，导致3，4条很难深入，最后就变成1，2条流于形式了，这也是我头痛的问题。