筆者在一家日本企業裏面從事軟件開發工作。作爲一家典型的日本企業，軟件開發的流程顯然是按着日本的軟件工程方式進行的。同樣作爲一家日企，在很多方面和歐美企業有着截然不同的開發角度。這裏想討論的，就是對Review和對Test的一些看法
日本企業對review是十分看重的。他們認爲review是解決bug最好的辦法，在開發中甚至會採用過度review的辦法。
比較典型的是我們開發課長的想法:既然現在在工業生產領域不是在產品製造出來之後通過測試來判斷質量，同樣的軟件開發就不應該通過測試來保證質量，而應該通過反覆的review，來保證代碼的質量。在這樣的思想指導下甚至於把review作爲通過CMMI的標準。
我認爲這裏存在三點問題。
一，把軟件開發等同於工業生產。這是絕對不正確的。軟件開發是一個高智力的活動，而不是零件的生產，每個部件都一樣。在所謂構件時代沒有大規模應用的時候，起碼現在的軟件更像一種工藝學，而不是工程學其含義就是，軟件開發，更多的是一種漸進成熟的過程，代碼從核心草案（有時候我們稱之爲詳細設計）到最終成品（有時候我們稱之爲release）是要通過不斷的測試才能漸進成熟。所謂測試，是把軟件模塊放到真是或者模擬真實的環境中去運行才能知道答案，這有點像科學研究。而review,更多的像是紙上談兵。讓一羣沒有參與代碼開發的人對着陌生的代碼看，要發現隱藏的bug？天方夜談。
二，Review更像是一種作坊的產物，沒有客觀的評價標準，沒有自動化工具，在大型項目，動輒幾萬行的代碼中去尋找可能的bug，顯然是不太可能的。如果硬要把軟件工程比作建築工程的話，review就好像用肉眼去觀察每一塊磚，每一面牆，只能有主觀的影響，而真正的需要檢驗質量的時候，需要的是尺子和吊線，當使用這些工具的時候，對應於軟件開發，就可以稱爲測試了。
三，現代軟件開發中，所提倡的XP方法，都是以測試優先的，包括微軟在內，所採用的開發方式也是測試優先，他們有專門的測試工程師，卻沒有Review工程師。死抱着Review的開發態度，只能讓軟件開發走入死衚衕。
