Code Review是軟件工程中很有意義的一個活動

        Code reviews 是一種傳遞知識的過程，可以讓不熟悉代碼的人知道作者的意圖和想法，從而可以輕松地維護代碼。 Code reviews 時，可以通過大家的建議提高代碼的質量和成熟度。 Code reviews 也可以促進大家相互學習對方的長處和優點。 Code reviews 也可以被用來確認自己的設計和實現，是一個非常優秀的實現。

      Code reviews 確實有很多用處，而在實際工作中它被用來找到程序bug、保證代碼風格、編碼標準。過于負擔了。它 不應該承擔發現代碼錯誤的職責，而是審核代碼的質量，如可讀性，可維護性，健壯性以及程序邏輯對需求的實現正確完整性。程序中的bug應該由單元測試、集 成測試、性能測試、系統測試、回歸測試來保證的，其中主要是單元測試是最重要的環節，因為那是最接近Bug，也是Bug沒有擴散的地方。

      它不應該成為保證代碼風格和編碼標準的手段。編碼風格和代碼規范都屬于死的東西，每個程序員在把自己的代碼提交團隊Review的時候，代碼就應該是符合規范的，這是默認值，屬于每個人自己的事情，不應該交由團隊來完成，否則只會浪費大家本來就不夠的時間。

      今天，在中國的很多公司里，上面這兩件事依然被認為是Code Reivew最重要的事，但在實際工作中夠看到很多開發Team抱怨Code Review就是一個形式，費時費力不說，發現的問題還不如測試。對于代碼規范，這應該是程序作者自己需要保證的，而且有一些工具是可以幫你來檢查代碼規 范的。

       上述言論并不是說，在Code Review中報告一個程序的bug或是一個代碼規范的問題。我只是說，那并不是Code Review的意圖。

       如何使Code Review更有意義。

       經常進行Code Review。就好像人家都把整個房子蓋好了，大家Review時這挑一點、那挑一點，有時候觸動地基或是承重墻體，需要大動手術，讓人返工，這當然會讓 蓋房的人一下就跳起來極力地維護自己的代碼，最后還傷了團隊成員的感情。所以，千萬不要等大廈都蓋好了再去Reivew，而且當有了地基，有了框架，有了 房頂，有了門窗，有了裝修的各個時候循序漸進地進行Review，這樣反而會更有效率，也更有幫助。當然，在敏捷開發中，他們不需要Code Reivew，其實，敏捷開發中使用更為極端的“結對編程”（Pair-Programming）的方法 —— 一種時時刻刻都在進行Code Review的方法，個人感覺在實際過程中，這種方法有點過了。

      保持積極的正面的態度。程序最大的問題就是“自負”，程序員在Code Review的時候，開始抨擊別人的代碼，質疑別人的能力。他們指責對方的目的是想告訴大家自己有多么的牛。無論是代碼作者，還是評審者，都需要一種積極 向上的正面的態度，作者需要能夠虛心接受別人的建議，因為別人的建議是為了讓你做得更好；評審者也需要以一種積極的正面的態度向作者提意見，因為那是和你 在一個戰壕里的戰友。

      Code Review不要太正式，而且要短。忘了那個代碼評審的Checklist吧，走到你的同事座位跟前，像請師父一樣請 他坐到你的電腦面前，然后，花5分鐘給他講講你的代碼，給他另外一個5分鐘讓他給你的代碼提提意見，這比什么都好。

       盡可能的讓不同的人Reivew你的代碼。不同的人有不同的思考方式，有不同的見解，所以，不同的人可以全面的從各個方面評論你的代碼，有的從實現的角 度，有的從需求的角度，有的從用戶使用的角度，有的從算法的角度，有的從性能效率的角度，有的從易讀的角度，有的從擴展性的角度……。當然，不要太多了， 人多嘴雜反而適得其反。