首先，我們先來(lái)看看Code Reivew的用處：

1. Code reviews 中，可以通過(guò)大家的建議增進(jìn)代碼的質(zhì)量。
2. Code reviews 是一個(gè)傳遞知識(shí)的手段，可以讓其他并不熟悉代碼的人知道作者的意圖和想法，從而可以在以后輕松維護(hù)代碼。
3. Code reviews 也鼓勵(lì)程序員們相互學(xué)習(xí)對(duì)方的長(zhǎng)處和優(yōu)點(diǎn)。
4. Code reviews 也可以被用來(lái)確認(rèn)自己的設(shè)計(jì)和實(shí)現(xiàn)是一個(gè)清楚和簡(jiǎn)單的。

　　你也許注意到了在上面的Code Reivew中的諸多用處中，我們沒(méi)有提到可以幫助找到程序的bug和保證代碼風(fēng)格和編碼標(biāo)準(zhǔn)。這是因?yàn)槲覀冋J(rèn)為：

1. Code reviews 不應(yīng)該承擔(dān)發(fā)現(xiàn)代碼錯(cuò)誤的職責(zé)。Code Review主要是審核代碼的質(zhì)量，如可讀性，可維護(hù)性，以及程序的邏輯和對(duì)需求和設(shè)計(jì)的實(shí)現(xiàn)。代碼中的bug和錯(cuò)誤應(yīng)該由單元測(cè)試，功能測(cè)試，性能測(cè)試，回歸測(cè)試來(lái)保證的（其中主要是單元測(cè)試，因?yàn)槟鞘亲罱咏麭ug，也是Bug沒(méi)有擴(kuò)散的地方）。
2. Code reviews 不應(yīng)該成為保證代碼風(fēng)格和編碼標(biāo)準(zhǔn)的手段。編碼風(fēng)格和代碼規(guī)范都屬于死的東西，每個(gè)程序員在把自己的代碼提交團(tuán)隊(duì)Review的時(shí)候，代碼就應(yīng)該是符合規(guī)范的，這是默認(rèn)值，屬于每個(gè)人自己的事情，不應(yīng)該交由團(tuán)隊(duì)來(lái)完成，否則只會(huì)浪費(fèi)大家本來(lái)就不夠的時(shí)間。我個(gè)人認(rèn)為“meeting”是奢侈的，因?yàn)槟切枰蠹以谕粫r(shí)刻都擠出時(shí)間，所以應(yīng)該用在最需要的地方。代碼規(guī)范比起程序的邏輯和對(duì)需求設(shè)計(jì)的實(shí)現(xiàn)來(lái)說(shuō)，太不值得讓大家都來(lái)了。

　　10年前，上面這兩件事會(huì)是理所當(dāng)然的（10年前的中國(guó)的軟件開(kāi)發(fā)還沒(méi)有Code Reivew呢）。今天，在中國(guó)的很多公司上面這兩件事依然被認(rèn)為是Code Reivew最重要的事。所以，我能夠看到很多開(kāi)發(fā)Team抱怨Code Review就是一個(gè)形式，費(fèi)時(shí)費(fèi)力不說(shuō)，發(fā)現(xiàn)的問(wèn)題還不如測(cè)試，而評(píng)審者們除了在代碼風(fēng)格上有些見(jiàn)術(shù)，別的也就沒(méi)什么用了，長(zhǎng)而久之，大家都會(huì)開(kāi)始厭煩這個(gè)事了。

　　所以，在今天，請(qǐng)不要把上面的那兩件事分散了Code Review的注意力，取而代之的是，對(duì)于Bug，程序的作者要在Review前提交自己的單元測(cè)試報(bào)告（如：XUnit的測(cè)試結(jié)果），對(duì)于代碼規(guī)范，這是程序作者自己需要保證的，而且，有一些工具是可以幫你來(lái)檢查代碼規(guī)范的。

　　當(dāng)然，上述這些言論并不是說(shuō)，你不能在Code Review中報(bào)告一個(gè)程序的bug或是一個(gè)代碼規(guī)范的問(wèn)題。我只是說(shuō)，那并不是Code Review的意圖。

　　下面是我們認(rèn)為的幾個(gè)小提示可以讓你更好進(jìn)行Code Review這項(xiàng)最有價(jià)值的活動(dòng)。

　　1. 經(jīng)常進(jìn)行Code Review

　　以前經(jīng)歷過(guò)幾個(gè)相當(dāng)痛苦的Code Review，那幾次Code Review都是在程序完成的時(shí)候進(jìn)行的，當(dāng)你面對(duì)那近萬(wàn)行的代碼，以前N多摻和在一起的功能，你會(huì)發(fā)現(xiàn)，整個(gè)Code Review變得非常地艱難，用不了一會(huì)兒，你就會(huì)發(fā)現(xiàn)大家都在拼命地打著哈欠，但還是要堅(jiān)持，有時(shí)候，這樣的Review會(huì)持續(xù)3個(gè)小時(shí)以上，相當(dāng)?shù)目鋸垺６遥瑫?huì)議上會(huì)出現(xiàn)相當(dāng)多的問(wèn)題和爭(zhēng)論，因?yàn)椋@就好像，人家都把整個(gè)房子蓋好了，大家Review時(shí)這挑一點(diǎn)那挑一點(diǎn)，有時(shí)候觸動(dòng)地基或是承重墻體，需要大動(dòng)手術(shù)，讓人返工，這當(dāng)然會(huì)讓蓋房的人一下就跳起來(lái)極力地維護(hù)自己的代碼，最后還傷了團(tuán)隊(duì)成員的感情。

　　所以，千萬(wàn)不要等大廈都蓋好了再去Reivew，而且當(dāng)有了地基，有了框架，有了房頂，有了門(mén)窗，有了裝修，在各個(gè)時(shí)候循序漸進(jìn)地進(jìn)行Review，這樣反而會(huì)更有效率，也更有幫助。

　　下面是一些觀點(diǎn)，千萬(wàn)要銘記：

• 要Review的代碼越多，那么要重構(gòu)，重寫(xiě)的代碼就會(huì)越多。而越不被程序作者接受的建議也會(huì)越多，唾沫口水戰(zhàn)也會(huì)越多。
• 程序員代碼寫(xiě)得時(shí)間越長(zhǎng)，程序員就會(huì)在代碼中加入越來(lái)越多的個(gè)人的東西。 程序員最大的問(wèn)題就是“自負(fù)”，無(wú)論什么時(shí)候，什么情況下，有太多的機(jī)會(huì)會(huì)讓這種“自負(fù)”澎漲開(kāi)來(lái)，并開(kāi)始影響團(tuán)隊(duì)影響整個(gè)項(xiàng)目，以至于聽(tīng)不見(jiàn)別人的建議，從而讓Code Review變成了口水戰(zhàn)。
• 越接近軟件發(fā)布的最終期限，代碼也就不能改得太多。

　　我個(gè)人的習(xí)慣，并且也是對(duì)團(tuán)隊(duì)成員的要求是——先Review設(shè)計(jì)實(shí)現(xiàn)思路，然后Review設(shè)計(jì)模式，接著Review成形的骨干代碼，最后Review完成的代碼，如果程序復(fù)雜的話，需要拆成幾個(gè)單元或模塊分別Review。當(dāng)然，最佳的practice是，每次Review的代碼應(yīng)該在1000行以內(nèi)，時(shí)間不能超過(guò)一部電影的時(shí)間——1.5小時(shí)（因?yàn)閾?jù)說(shuō)那個(gè)一個(gè)正常人的膀胱可以容納尿液的最長(zhǎng)限度）。

　　當(dāng)然，在敏捷開(kāi)發(fā)中，他們不需要Code Reivew，其實(shí)，敏捷開(kāi)發(fā)中使用更為極端的“結(jié)對(duì)編程”（Pair-Programming）的方法 —— 一種時(shí)時(shí)刻刻都在進(jìn)行Code Review的方法，個(gè)人感覺(jué)在實(shí)際過(guò)程中，這種方法有點(diǎn)過(guò)了。另外，大家可以看看本站的另一篇文章《結(jié)對(duì)編程的利與弊》來(lái)了解一下這種方法的問(wèn)題。

　　2. Code Review不要太正式，而且要短

　　忘了那個(gè)代碼評(píng)審的Checklist吧，走到你的同事座位跟前，像請(qǐng)師父一樣請(qǐng)他坐到你的電腦面前，然后，花5分鐘給他講講你的代碼，給他另外一個(gè)5分鐘讓他給你的代碼提提意見(jiàn)，這比什么都好。而如果你用了一個(gè)Checklist，讓這個(gè)事情表現(xiàn)得很正式的話，下面兩件事中必有一件事會(huì)發(fā)生：

　　1) 只有在Checklist上存在的東西才會(huì)被Review。

　　2) Code Reviews 變成了一種禮節(jié)性的東西，你的同事會(huì)裝做很關(guān)心你的代碼，但其實(shí)他心里想著盡快地離開(kāi)你。

　　只有不正式的Code Review才會(huì)讓你和評(píng)審者放輕松，人只有放松了，才會(huì)表現(xiàn)得很真實(shí)，很真誠(chéng)。記住Review只不過(guò)是一種形式，而只有在相互信任中通過(guò)相互的討論得到了有意義和有建設(shè)性的建議和意見(jiàn)，那才是最實(shí)在的。不然，作者和評(píng)審者的關(guān)系就會(huì)變成小偷和警察的關(guān)系。

　　3. 盡可能的讓不同的人Reivew你的代碼

　　這是一個(gè)好主意，如果可能的話，不要總是只找一個(gè)人來(lái)Review你的代碼，不同的人有不同的思考方式，有不同的見(jiàn)解，所以，不同的人可以全面的從各個(gè)方面評(píng)論你的代碼，有的從實(shí)現(xiàn)的角度，有的從需求的角度，有的從用戶使用的角度，有的從算法的角度，有的從性能效率的角度，有的從易讀的角度，有的從擴(kuò)展性的角度……，啊，好多啊，還讓不讓人活了。不管怎么說(shuō)，多找一些不同的人會(huì)對(duì)你很有好處。當(dāng)然，不要太多了，人多嘴雜反而適得其反，基本上來(lái)說(shuō)，不要超過(guò)3個(gè)人，這是因?yàn)椋@是一個(gè)可以圍在一起討論的最大人員尺寸。

　　下面是幾個(gè)優(yōu)點(diǎn)：

　　1) 從不同的方向評(píng)審代碼總是好的。

　　2) 會(huì)有更多的人幫你在日后維護(hù)你的代碼。

　　3) 這也是一個(gè)增加團(tuán)隊(duì)凝聚力的方法。

　　4. 保持積極的正面的態(tài)度

　　再說(shuō)一次，程序最大的問(wèn)題就是“自負(fù)”，尤其當(dāng)我們Reivew別人的代碼的時(shí)候，我已經(jīng)見(jiàn)過(guò)無(wú)數(shù)的場(chǎng)面，程序員在Code Review的時(shí)候，開(kāi)始抨擊別人的代碼，質(zhì)疑別人的能力。太可笑了，我分析了一下，這類的程序員其實(shí)并沒(méi)有什么本事，因?yàn)樗麄冎肛?zé)對(duì)方的目的是想告訴大家自己有多么的牛，靠這種手段來(lái)表現(xiàn)自己的程序員，其實(shí)是就是傳說(shuō)中所說(shuō)的“半瓶水”。

　　所以，無(wú)論是代碼作者，還是評(píng)審者，都需要一種積極向上的正面的態(tài)度，作者需要能夠虛心接受別人的建議，因?yàn)閯e人的建議是為了讓你做得更好；評(píng)審者也需要以一種積極的正面的態(tài)度向作者提意見(jiàn)，因?yàn)槟鞘呛湍阍谝粋€(gè)戰(zhàn)壕里的戰(zhàn)友。記住，你不是一段代碼，你是一個(gè)人！

　　5. 學(xué)會(huì)享受Code Reivew

　　這可能是最重要的一個(gè)提示了，如果你到了一個(gè)人人都喜歡Code Reivew的團(tuán)隊(duì)，那么，你會(huì)進(jìn)入到一個(gè)生機(jī)勃勃的地方，在那里，每個(gè)人都能寫(xiě)出質(zhì)量非常好的代碼，在那里，你不需要經(jīng)理的管理，團(tuán)隊(duì)會(huì)自適應(yīng)一切變化，他們相互學(xué)習(xí)，相互幫助，不僅僅是寫(xiě)出好的代碼，而且團(tuán)隊(duì)和其中的每個(gè)人都會(huì)自動(dòng)進(jìn)化，最關(guān)鍵的是，這個(gè)是一個(gè)團(tuán)隊(duì)。

it知識(shí)庫(kù)：Code Review中的幾個(gè)提示，轉(zhuǎn)載需保留來(lái)源！

鄭重聲明：本文版權(quán)歸原作者所有，轉(zhuǎn)載文章僅為傳播更多信息之目的，如作者信息標(biāo)記有誤，請(qǐng)第一時(shí)間聯(lián)系我們修改或刪除，多謝。