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

      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你的代碼。不一樣的人有不一樣的思考方式，有不一樣的看法，因此，不一樣的人能夠全面的從各個方面評論你的代碼，有的從實現的角度，有的從需求的角度，有的從用戶使用的角度，有的從算法的角度，有的從性能效率的角度，有的從易讀的角度，有的從擴展性的角度……。固然，不要太多了，人多嘴雜反而拔苗助長。

       學會享受Code Reivew。若是你到了一我的人都喜歡Code Reivew的團阿，那麼，你會進入到一個生機勃勃的地方，在那裏，每一個人都能寫出質量很是好的代碼，在那裏，他們相互學習，相互幫助，不單單是寫出好的代碼，並且團隊和其中的每一個人都會自動進化，這個是一個團隊。