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

ok。。。我只好说，我不适合这种管理方式
当然 我还是有兴趣尝试那么几次pair的 感觉就像玩大家一起来找茬-我经常跟老婆两个人一起玩这个游戏

跟老婆pair。。。寒。。。

不过习惯这个问题，我倒觉得人是应该有适应能力的。没试之前，最好不要说自己不适合。试了再说。

你们说的是什么类型的公司啊，国内绝大多数公司都不可能实行pair，
code review都是很稀有的事情。
老板要省成本，而且最喜欢在开发这一块省。

我个人倾向于多种方式结合的模式。有这几个要求:
1,只有在代码需要check in的时候才需要进行检查。结对人员必须无条件暂停工作进行code review.
2,代码检查分3个阶段进行:
  a,自动工具检查。使用IDE的插件功能进行检查。这类工具有Check Style,PMD,jTest等工具。我个人比较喜欢PMD，因为可以更容易组合规则，PMD支持大部分的IDE (Eclipse,IDEA,JBuilder,NetBeans....).
  b,个人自检。个人经过一定的修正后，个人再对照公司的代码规范和代码编写建议进行自检。
  c,Pair Review,结对检查。结对人员也可以再参考公司的规范和建议进行检查，同时还需要针对开发任务书进行代码检查。

但是以现行的很多公司来说。这样实施的开发成本较高。就跟做文档评审先需要进行文档评审准备会一样。但是如果能坚持实施，我个人认为对项目和组员都是有很大的帮助的。

之前也在寻找如何解决code review的途径，参考过的资料包括:
http://www.ibm.com/developerworks/cn/java/j-cq06306/index.html
“追求代码质量: 用代码度量进行重构(http://www.ibm.com/developerworks/cn/java/j-cq05306/index.html)”（Andrew Glover, developerWorks，2006 年 5 月）：用 Extract Method 模式进行重构和简化复杂代码。
这是IBM开发者社区的系列文章，我觉得很有帮助的。

pair感觉上比code review容易推广，
但事实上又看到code review的模式多一些。也许大家都更相信集体力量大， pair的人员组合是个问题， 应该是一个水平高点的带水平低一点的，很难找到合适资源吧。

如果老板这么说，我会忍不住亲他一口。
无休止的无意义的无薪酬的加班。
我已经忍无可忍。

传统的公司中，pair不可想象，

试问：领导者如何会乐意见到每时每刻都有一个人在“闲”着！

code review不能忽略的一个重要因素那就是人，人首先一个是懒惰的，不要说code review，就是unit test在开发中有少有人能够去做，尤其在开发工期紧的情况下，功能开发的时间都没有，号召开发人员做交叉review看他人写的代码，过于理想；其次是人有一个自我性，尤其是国内程序员，有可能会出现“你说我的代码味道不好，你算哪根葱”这种情况出现，所以一般code review比较理想是让team中的大拿来管，可是话说回来，大拿也很忙啊... code review有时候会成为一种形式，走一走，但是要真的拿它当真，除非你的公司开发水平到了那个档次，各方面保障都很好，否则有可能会引发意向不到的问题。这个度的把握要看团队成员情况和公司开发现状。

code review不是必须的，但是非常推荐。一个非常简单的理由，你敢把你的代码拿来让别人分析，挑毛病吗？你的代码和设计书真的一点问题也没有，我不相信，你如何保证你干的活的质量，一个人全权负责？如果可以，说明你的客户只需要这样的质量。比如以前做过的金融的项目，有问题的时候，会有罚款，你说你如何保证质量，review，不单是代码，全部让别人review，能在相当的程度上避免很多问题，但是不是所有。

有一个问题要搞清楚，必须要做的事情，可选的事情。可选不可选不是由具体的干活的人决定的，是由项目负责的人决定的。如果由于时间紧，比较困难，是如何做的问题，什么形式做，什么时候作，谁来做的问题，时间紧不是不做的理由，做不做负责人判断。具体写代码的人没有权利选择，但是如果你被赋权了。

code review本身并不无聊，从这个可以透视出很多的问题。尤其是质量问题。

pair?巴不得一个人干两个人的活，还俩人干一个人的活。。。