Code Review中的幾個提示

原文：http://coolshell.cn/?p=1302酷殼

code review中的幾個提示

陳皓

code review應該是軟體工程最最有價值的乙個活動，之前，本站發表過《簡單實用的code review工具

首先，我們先來看看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這項最有價值的活動。

以前經歷過幾個相當痛苦的code review，那幾次code review都是在程式完成的時候進行的，當你面對那近萬行的**，以前n我摻和在一起的功能，你會發現，整個code review變得非常地艱難，用不了一會兒，你就會發現大家都在拼命地打著哈欠，但還是要堅持，有時候，這樣的review會持續3個小時以上，相當的誇張。而且，會議上會出現相當多的問題和爭論，因為，這就好像，人家都把整個房子蓋好了，大家review時這挑一點那挑一點，有時候觸動地基或是承重牆體，需要大動手術，讓人返工，這當然會讓蓋房的人一下就跳起來極力地維護自己的**，最後還傷了團隊成員的感情。

所以，千萬不要等大廈都蓋好了再去reivew，而且當有了地基，有了框架，有了房頂，有了門窗，有了裝修，的各個時候循序漸進地進行review，這樣反而會更有效率，也更有幫助。

下面是一些觀點，千萬要銘記：

我個人的習慣，並且也是對團隊成員的要求是——先review設計實現思路，然後review設計模式，接著review成形的骨幹**，最後review完成的**，如果程式複雜的話，需要拆成幾個單元或模組分別review。當然，最佳的practice是，每次review的**應該在1000行以內，時間不能超過一部電影的時間——1.5小時（因為據說那個乙個正常人的膀胱可以容納尿液的最長限度）

當然，在敏捷開發中，他們不需要code reivew，其實，敏捷開發中使用更為極端的「結對程式設計」（pair-programming）的方法 —— 一種時時刻刻都在進行code review的方法，個人感覺在實際過程中，這種方法有點過了。另外，大家可以看看本站的另一篇文章《結對程式設計的利與弊

》來了解一下這種方法的問題。

忘了那個**評審的checklist吧，走到你的同事座位跟前，像請**一樣請他坐到你的電腦面前，然後，花5分鐘給他講講你的**，給他另外乙個5分鐘讓他給你的**提提意見，這比什麼都好。而如果你用了乙個checklist，讓這個事情表現得很正式的話，下面兩件事中必有一件事會發生：

只有在checklist上存在的東西會被review。

code reviews 變成了一種禮節性的東西，你的同事會裝做很關心你的**，但其實他心裡想著盡快地離開你。

只有不正式的code review才會讓你和評審者放輕鬆，人只有放鬆了，才會表現得很真實，很真誠。記住review只不過是一種形式，而只有通過相互的討論得到了有意義和有建設性的建議和意見，那才是最實在的。不然，作者和評審者的關係就會變成小偷和警察的關係。

下面是幾個優點：

從不同的方向評審**總是好的。

會有更多的人幫你在日後維護你的**。

這也是乙個增加團隊凝聚力的方法。

再說一次，程式最大的問題就是「自負」，尤其當我們reivew別人的**的時候，我已經見過無數的場面，程式設計師在code review的時候，開始抨擊別人的**，質疑別人的能力。太可笑了，我分析了一下，這類的程式設計師其實並沒有什麼本事，因為他們指責對方的目的是想告訴大家自己有多麼的牛，其實，靠這種手段來表現自己的程式設計師，其實是就是傳說中所說的「半瓶水」。

所以，無論是**作者，還是評審者，都需要一種積極向上的正面的態度，作者需要能夠虛心接受別人的建議，因為別人的建議是為了讓你做得更好；評審者也需要以一種積極的正面的態度向作者提意見，因為那是和你在乙個戰壕裡的戰友。記住，你不是一段**，你是乙個人！

這可能是最重要的乙個提示了，如果你到了乙個人人都喜歡code reivew的團阿，那麼，你會進入到乙個生機勃勃的地方，在那裡，每個人都能寫出質量非常好的**，在那裡，你不需要經理的管理，團隊會自適應一切變化，他們相互學習，相互幫助，不僅僅是寫出好的**，而且團隊和其中的每個人都會自動進化，最關鍵的是，這個是乙個團隊。

Code Review中的幾個提示

Code Review中的幾個提示

Code Review中的幾個提示

簡單舉幾個CodeReview的常見錯誤

相關推薦