從infoQ官網看到的一個文章，“設計和代碼審查：是好、是壞還是不堪入目？”，深有感觸，談談自己的一些親身經歷，發發牢騷吧。
原文在http://www.infoq.com/cn/news/2008/03/code-review-antipatterns，建議先看原文。
作者在文章開頭提到，“復查的承諾是改進軟件質量、確保與標準的一致性，并且可以作為一種有價值的工具為開發人員服務，但是它們的執行方式卻影響到了自身的價值。在某些組織中，它們可能真的見效；而在另一些地方，可能也不過是官僚作風的一種體現而已。”
最近我們部門也在進行代碼審查，去年年底做過一次，現在還在做?？墒?，我很遺憾的發現，我們的工作是更多的是驗證了上面的擔憂，“不過是官僚作風的一種體現”。
對照了一下，發現以下問題普遍存在，簡直就是在點名說我們的感覺：
迫害式復查——編寫代碼的開發人員有被攻擊的感覺，甚感恐懼。
樵夫式復查——一直等到代碼庫變成龐然大物再進行復查，而這時要進行完整的復查已經變成了難如登天且事倍功半的任務。
令箭式復查——將復查活動形式化，只因為是管理層打算這樣做。
而且由于“樵夫式復查”的存在，為了讓復查能進行下去，又犯了下面的錯誤：
排它性復查——只拿出代碼中的某一段樣本來進行復查，把其他重要的部分都棄而不顧。
可以想象這樣的復查過程，能有多少效果可言。領導拍拍腦袋，說要復查，要如何如何，天花亂墜的一堆。那我們這些作為下面實際干活的程序員該如何應對？
這里有一個實例：我的一個同事，性格非常負責的，很投入的去進行復查，找出了很多問題，發現了很多需要改動的地方，整理出了一封比較中肯的整改方案。郵件發出去了，我看了，可是我知道領導們和其他開發肯定不會細看。這個事情發現在去年年底的第一次復查，這個郵件果然是石沉大海，渺無音訊，那次的復查不了了之，仿佛沒有發生。
這個月，領導似乎又想起來了，拍拍腦袋又提出復查。于是下面又動起來了，依然是會議先行，呵呵。會議上，依然是洋洋萬言，但是，當這位同事問起，上次的整改建議，大家看過沒有？ 一切假象都消失了，原來不過是領導和大家一起忽悠而已，認真的只有他一人。復查的過程“據說”還在進行，但是結果，我想用腳趾頭都可以想到的。
我因為手頭有項目需求，沒有參與上述的復查過程，或者說是逃過了。
但是如果我沒有逃過呢，我該如何？
當領導和大部分人都在忽悠時，我該如何？
你又該如何？