|
|
首先，我們先來看看Code Reivew的用處：
- Code reviews 中，可以通過大家的建議增進代碼的質量。
- Code reviews 是一個傳遞知識的手段，可以讓其他并不熟悉代碼的人知道作者的意圖和想法，從而可以在以后輕松維護代碼。
- Code reviews 也鼓勵程序員們相互學習對方的長處和優點。
- Code reviews 也可以被用來確認自己的設計和實現是一個清楚和簡單的。
你也許注意到了在上面的Code Reivew中的諸多用處中，我們沒有提到可以幫助找到程序的bug和保證代碼風格和編碼標準。這是因為我們認為：
- Code reviews 不應該承擔發現代碼錯誤的職責。Code Review主要是審核代碼的質量，如可讀性，可維護性，以及程序的邏輯和對需求和設計的實現。代碼中的bug和錯誤應該由單元測試，功能測試，性能測試，回歸測試來保證的（其中主要是單元測試，因為那是最接近Bug，也是Bug沒有擴散的地方）。
- Code reviews 不應該成為保證代碼風格和編碼標準的手段。編碼風格和代碼規范都屬于死的東西，每個程序員在把自己的代碼提交團隊Review的時候，代碼就應該是符合規范的，這是默認值，屬于每個人自己的事情，不應該交由團隊來完成，否則只會浪費大家本來就不夠的時間。我個人認為“meeting”是奢侈的，因為那需要大家在同一時刻都擠出時間，所以應該用在最需要的地方。代碼規范比起程序的邏輯和對需求設計的實現來說，太不值得讓大家都來了。
10年前，上面這兩件事會是理所當然的（10年前的中國的軟件開發還沒有Code Reivew呢）。今天，在中國的很多公司上面這兩件事依然被認為是Code Reivew最重要的事。所以，我能夠看到很多開發Team抱怨Code Review就是一個形式，費時費力不說，發現的問題還不如測試，而評審者們除了在代碼風格上有些見術，別的也就沒什么用了，長而久之，大家都會開始厭煩這個事了。
所以，在今天，請不要把上面的那兩件事分散了Code Review的注意力，取而代之的是，對于Bug，程序的作者要在Review前提交自己的單元測試報告（如：XUnit的測試結果），對于代碼規范，這是程序作者自己需要保證的，而且，有一些工具是可以幫你來檢查代碼規范的。
當然，上述這些言論并不是說，你不能在Code Review中報告一個程序的bug或是一個代碼規范的問題。我只是說，那并不是Code Review的意圖。
下面是我們認為的幾個小提示可以讓你更好進行Code Review這項最有價值的活動。
1. 經常進行Code Review
以前經歷過幾個相當痛苦的Code Review，那幾次Code Review都是在程序完成的時候進行的，當你面對那近萬行的代碼，以前N多摻和在一起的功能，你會發現，整個Code Review變得非常地艱難，用不了一會兒，你就會發現大家都在拼命地打著哈欠，但還是要堅持，有時候，這樣的Review會持續3個小時以上，相當的夸張。而且，會議上會出現相當多的問題和爭論，因為，這就好像，人家都把整個房子蓋好了，大家Review時這挑一點那挑一點，有時候觸動地基或是承重墻體，需要大動手術，讓人返工，這當然會讓蓋房的人一下就跳起來極力地維護自己的代碼，最后還傷了團隊成員的感情。
所以，千萬不要等大廈都蓋好了再去Reivew，而且當有了地基，有了框架，有了房頂，有了門窗，有了裝修，在各個時候循序漸進地進行Review，這樣反而會更有效率，也更有幫助。
下面是一些觀點，千萬要銘記：
- 要Review的代碼越多，那么要重構，重寫的代碼就會越多。而越不被程序作者接受的建議也會越多，唾沫口水戰也會越多。
- 程序員代碼寫得時間越長，程序員就會在代碼中加入越來越多的個人的東西。 程序員最大的問題就是“自負”，無論什么時候，什么情況下，有太多的機會會讓這種“自負”澎漲開來，并開始影響團隊影響整個項目，以至于聽不見別人的建議，從而讓Code Review變成了口水戰。
- 越接近軟件發布的最終期限，代碼也就不能改得太多。
我個人的習慣，并且也是對團隊成員的要求是——先Review設計實現思路，然后Review設計模式，接著Review成形的骨干代碼，最后Review完成的代碼，如果程序復雜的話，需要拆成幾個單元或模塊分別Review。當然，最佳的practice是，每次Review的代碼應該在1000行以內，時間不能超過一部電影的時間——1.5小時（因為據說那個一個正常人的膀胱可以容納尿液的最長限度）。
當然，在敏捷開發中，他們不需要Code Reivew，其實，敏捷開發中使用更為極端的“結對編程”（Pair-Programming）的方法 —— 一種時時刻刻都在進行Code Review的方法，個人感覺在實際過程中，這種方法有點過了。另外，大家可以看看本站的另一篇文章《結對編程的利與弊》來了解一下這種方法的問題。
2. Code Review不要太正式，而且要短
忘了那個代碼評審的Checklist吧，走到你的同事座位跟前，像請師父一樣請他坐到你的電腦面前，然后，花5分鐘給他講講你的代碼，給他另外一個5分鐘讓他給你的代碼提提意見，這比什么都好。而如果你用了一個Checklist，讓這個事情表現得很正式的話，下面兩件事中必有一件事會發生：
1) 只有在Checklist上存在的東西才會被Review。
2) Code Reviews 變成了一種禮節性的東西，你的同事會裝做很關心你的代碼，但其實他心里想著盡快地離開你。
只有不正式的Code Review才會讓你和評審者放輕松，人只有放松了，才會表現得很真實，很真誠。記住Review只不過是一種形式，而只有在相互信任中通過相互的討論得到了有意義和有建設性的建議和意見，那才是最實在的。不然，作者和評審者的關系就會變成小偷和警察的關系。
3. 盡可能的讓不同的人Reivew你的代碼
這是一個好主意，如果可能的話，不要總是只找一個人來Review你的代碼，不同的人有不同的思考方式，有不同的見解，所以，不同的人可以全面的從各個方面評論你的代碼，有的從實現的角度，有的從需求的角度，有的從用戶使用的角度，有的從算法的角度，有的從性能效率的角度，有的從易讀的角度，有的從擴展性的角度……，啊，好多啊，還讓不讓人活了。不管怎么說，多找一些不同的人會對你很有好處。當然，不要太多了，人多嘴雜反而適得其反，基本上來說，不要超過3個人，這是因為，這是一個可以圍在一起討論的最大人員尺寸。
下面是幾個優點：
1) 從不同的方向評審代碼總是好的。
2) 會有更多的人幫你在日后維護你的代碼。
3) 這也是一個增加團隊凝聚力的方法。
4. 保持積極的正面的態度
再說一次，程序最大的問題就是“自負”，尤其當我們Reivew別人的代碼的時候，我已經見過無數的場面，程序員在Code Review的時候，開始抨擊別人的代碼，質疑別人的能力。太可笑了，我分析了一下，這類的程序員其實并沒有什么本事，因為他們指責對方的目的是想告訴大家自己有多么的牛，靠這種手段來表現自己的程序員，其實是就是傳說中所說的“半瓶水”。
所以，無論是代碼作者，還是評審者，都需要一種積極向上的正面的態度，作者需要能夠虛心接受別人的建議，因為別人的建議是為了讓你做得更好；評審者也需要以一種積極的正面的態度向作者提意見，因為那是和你在一個戰壕里的戰友。記住，你不是一段代碼，你是一個人！
5. 學會享受Code Reivew
這可能是最重要的一個提示了，如果你到了一個人人都喜歡Code Reivew的團隊，那么，你會進入到一個生機勃勃的地方，在那里，每個人都能寫出質量非常好的代碼，在那里，你不需要經理的管理，團隊會自適應一切變化，他們相互學習，相互幫助，不僅僅是寫出好的代碼，而且團隊和其中的每個人都會自動進化，最關鍵的是，這個是一個團隊。
it知識庫：Code Review中的幾個提示，轉載需保留來源！
鄭重聲明：本文版權歸原作者所有，轉載文章僅為傳播更多信息之目的，如作者信息標記有誤，請第一時間聯系我們修改或刪除，多謝。
