从infoQ官网看到的一个文章，“设计和代码审查：是好、是坏还是不堪入目？”，深有感触，谈谈自己的一些亲身经历，发发牢骚吧。
原文在http://www.infoq.com/cn/news/2008/03/code-review-antipatterns，建议先看原文。
作者在文章开头提到，“复查的承诺是改进软件质量、确保与标准的一致性，并且可以作为一种有价值的工具为开发人员服务，但是它们的执行方式却影响到了自身的价值。在某些组织中，它们可能真的见效；而在另一些地方，可能也不过是官僚作风的一种体现而已。”
最近我们部门也在进行代码审查，去年年底做过一次，现在还在做。可是，我很遗憾的发现，我们的工作是更多的是验证了上面的担忧，“不过是官僚作风的一种体现”。
对照了一下，发现以下问题普遍存在，简直就是在点名说我们的感觉：
迫害式复查——编写代码的开发人员有被攻击的感觉，甚感恐惧。
樵夫式复查——一直等到代码库变成庞然大物再进行复查，而这时要进行完整的复查已经变成了难如登天且事倍功半的任务。
令箭式复查——将复查活动形式化，只因为是管理层打算这样做。
而且由于“樵夫式复查”的存在，为了让复查能进行下去，又犯了下面的错误：
排它性复查——只拿出代码中的某一段样本来进行复查，把其他重要的部分都弃而不顾。
可以想象这样的复查过程，能有多少效果可言。领导拍拍脑袋，说要复查，要如何如何，天花乱坠的一堆。那我们这些作为下面实际干活的程序员该如何应对？
这里有一个实例：我的一个同事，性格非常负责的，很投入的去进行复查，找出了很多问题，发现了很多需要改动的地方，整理出了一封比较中肯的整改方案。邮件发出去了，我看了，可是我知道领导们和其他开发肯定不会细看。这个事情发现在去年年底的第一次复查，这个邮件果然是石沉大海，渺无音讯，那次的复查不了了之，仿佛没有发生。
这个月，领导似乎又想起来了，拍拍脑袋又提出复查。于是下面又动起来了，依然是会议先行，呵呵。会议上，依然是洋洋万言，但是，当这位同事问起，上次的整改建议，大家看过没有？ 一切假象都消失了，原来不过是领导和大家一起忽悠而已，认真的只有他一人。复查的过程“据说”还在进行，但是结果，我想用脚趾头都可以想到的。
我因为手头有项目需求，没有参与上述的复查过程，或者说是逃过了。
但是如果我没有逃过呢，我该如何？
当领导和大部分人都在忽悠时，我该如何？
你又该如何？