建站
咨詢
售后
建站咨詢
新聞中心
數(shù)百萬年前，猿從樹上下來，進(jìn)化出了對生拇指，最終，變成了人類。
在臨沭等地區(qū)，都構(gòu)建了全面的區(qū)域性戰(zhàn)略布局，加強(qiáng)發(fā)展的系統(tǒng)性、市場前瞻性、產(chǎn)品創(chuàng)新能力，以專注、極致的服務(wù)理念，為客戶提供成都網(wǎng)站制作、網(wǎng)站設(shè)計(jì) 網(wǎng)站設(shè)計(jì)制作按需定制,公司網(wǎng)站建設(shè),企業(yè)網(wǎng)站建設(shè),品牌網(wǎng)站建設(shè),營銷型網(wǎng)站建設(shè),成都外貿(mào)網(wǎng)站制作,臨沭網(wǎng)站建設(shè)費(fèi)用合理。
我們以類似的眼光來看下強(qiáng)制性代碼審查（Code Review）：好像是一種能在軟件開發(fā)這塊廣闊的領(lǐng)域里將人類從獸里分離出來的東西。
不過，我有時(shí)候會(huì)從我們的團(tuán)隊(duì)成員里聽到下面這樣的評論：
- “這個(gè)項(xiàng)目的代碼審查根本就是浪費(fèi)時(shí)間?！?/li>
- “我沒有時(shí)間做代碼審查?！?/li>
- “我的項(xiàng)目發(fā)布延期了，都是因?yàn)槲夷桥橙醯耐逻€沒有做任何審查?！?/li>
- “你能相信我的同事竟想讓我在代碼中改點(diǎn)東西嗎？請向他們解釋：如果我那最初的優(yōu)雅代碼受到任何方式改動(dòng)的話，那就意味著宇宙微妙的平衡將要遭到破壞。”
為什么我們要做代碼審查？
首先，讓我們謹(jǐn)記為什么要做代碼審查。對于任何專業(yè)的軟件開發(fā)人員來說，最重要的目標(biāo)之一是能夠持續(xù)的提高他們的工作質(zhì)量。即使你的團(tuán)隊(duì)里盡是優(yōu)秀的程序員，你也不能將你自己與一個(gè)有能力的自由從業(yè)者區(qū)分開來，除非你能夠作為一個(gè)團(tuán)隊(duì)工作。代碼審查是達(dá)到這個(gè)目的的最重要方式之一。尤其，它們：
- 給予你第二雙眼睛來找到做某些事的瑕疵和更好的方法。
- 確保至少有一個(gè)其他人員熟悉你的代碼。
- 通過向新員工展示更有經(jīng)驗(yàn)的開發(fā)者的代碼來幫助訓(xùn)練他們。
- 通過讓審查者和被審查者互相展示好的想法和做法以促進(jìn)知識分享。
- 鼓勵(lì)開發(fā)者在他們的工作中更加盡心盡力，因?yàn)樗麄冎雷约旱拇a將來要被他們的的某個(gè)同事審查。
做徹底深入的審查
不過，如果不在審查工作上傾注一定的時(shí)間和精力，這些目標(biāo)都是無法實(shí)現(xiàn)的。僅僅滾動(dòng)瀏覽下patch，確?？s進(jìn)正確、所有的變量采取小駱駝拼寫法并不能構(gòu)成一次徹底的審查。受到業(yè)界的啟發(fā)也可以考慮結(jié)對編程，這是一個(gè)相當(dāng)流行的做法，但也在所有的開發(fā)時(shí)間上增加了100%的額外開銷來作為代碼審查工作的基準(zhǔn)。你可能會(huì)在代碼審查中花費(fèi)很多時(shí)間，但與結(jié)對編程相比，使用的總體工程時(shí)間仍少得多。
我認(rèn)為花在代碼審查工作上的時(shí)間應(yīng)該是原開發(fā)時(shí)間的25%左右。例如，如果一個(gè)開發(fā)者花兩天時(shí)間實(shí)現(xiàn)了個(gè)小項(xiàng)目，那么審查者應(yīng)該花大致4個(gè)小時(shí)的時(shí)間來審查它。
當(dāng)然，花在審查工作上多少時(shí)間并不是最重要的，只要審查能夠準(zhǔn)確無誤的完成即可。特別地，你必須要能理解你正在審查的代碼。這不僅僅意味著你只要懂該代碼所采用語言的語法即可，它還意味著你必須了解該代碼如何適應(yīng)于更大的應(yīng)用環(huán)境、組件或庫下。如果你不抓住每一行代碼的全部含義，那么你的審查就不是非常有價(jià)值的。這也是為什么好的審查都不可能非常快的完成：因?yàn)檫€要花時(shí)間去調(diào)查觸發(fā)某個(gè)給定函數(shù)的不同代碼路徑，要去確保第三方API能夠正確使用（包括任何邊緣情況），等等。
除了尋找你所審查的代碼中的瑕疵或其它問題之外，你還應(yīng)該確保：
- 包含所有必要的測試。
- 合適的設(shè)計(jì)文檔已經(jīng)寫完。
甚至擅長寫測試和文檔的開發(fā)人員也并不總能記得在代碼改動(dòng)之后及時(shí)更新。在適當(dāng)?shù)臅r(shí)候來自代碼審查人員的細(xì)微調(diào)整對于確保代碼在隨著時(shí)間的推移不會(huì)變質(zhì)是至關(guān)重要的。
防止代碼審查工作超負(fù)荷
如果你的團(tuán)隊(duì)強(qiáng)制要求做代碼審查，那這是有風(fēng)險(xiǎn)的，因?yàn)槟愕拇a審查工作可能一直積壓，最終到無法管理的地步。如果你兩周之內(nèi)不做任何審查工作，你可以很容易的花上幾天時(shí)間來趕補(bǔ)它。不過這也意味著當(dāng)你最終決定去處理它們的時(shí)候，你自己的開發(fā)工作將遭到一定的意外擱淺。這也使得做好審查工作更加困難，因?yàn)檎_的代碼審查需要強(qiáng)烈、持續(xù)的腦力勞動(dòng)，很難這樣數(shù)日保持下去。
因此，開發(fā)者每天應(yīng)該竭盡全力的清空他們的審查積壓工作。一個(gè)方法是早晨的第一件事情就用來解決審查工作。在開始自己的開發(fā)工作之前先做完所有的優(yōu)秀審查工作，你可以防止以后的審查局面失控情況。有些人更喜歡在午休之前或之后或在一天結(jié)束后做審查工作。無論你什么時(shí)候做這些事情，通過將代碼審查作為正規(guī)的日常工作而不是作為一種分散注意力的工作，你可以避免：
- 沒有時(shí)間處理你的審查積壓工作。
- 因?yàn)槟愕膶彶楣ぷ鬟€沒做完而延遲項(xiàng)目的發(fā)布。
- 做出一些不再相關(guān)的審查，因?yàn)樵诖似陂g代碼已經(jīng)改動(dòng)的非常多。
- 因?yàn)橼s在最后一分鐘處理它們而導(dǎo)致審查工作最終完成的很差。
寫易于審查的代碼
無法管理的審查積壓工作也不能全怪審查人員。如果我的同事不管三七二十一的花費(fèi)一周的時(shí)間來給一個(gè)大工程項(xiàng)目添加代碼，那么他們發(fā)布的patch將真的很難審查，因?yàn)樵谝粋€(gè)階段里有太多的工作要處理，代碼的目的和底層架構(gòu)體系也會(huì)很難理解。
這是將你的工作切割為一個(gè)個(gè)可管理單元之所以非常重要的眾多原因之一，我們使用scrum管理方法，所以對我們來說合適的單元是重點(diǎn)。通過一起努力，用單元來組織我們的工作，并提交僅與我們正在進(jìn)行的某個(gè)單元相關(guān)的審查，我們可以寫出更加易于審查的代碼。你的團(tuán)隊(duì)可能使用另一種管理方法，但是原則都是一樣的。
為了寫出易于審查的代碼，還有一些其它的必備條件。如果要做出一些很棘手的架構(gòu)決策，為滿足審查者的要求，事先進(jìn)行討論是合理的。這將使得審查者更加容易的理解你的代碼，因?yàn)樗麄儗⒅滥阍诖a中試著達(dá)到什么目的以及怎么計(jì)劃來達(dá)到該目的。這也有助于避免這樣一種情況：在審查者提出一個(gè)不同的更好的方法后，你必須要重寫你的大段代碼。
在你的設(shè)計(jì)文檔里項(xiàng)目架構(gòu)應(yīng)該要詳細(xì)的描述。這無論如何都是很重要的，因?yàn)樗茏屢粋€(gè)新的項(xiàng)目成員很快的趕上進(jìn)度并理解現(xiàn)有的代碼庫。它還能幫助審查者更好的做好自己的工作，這是另一個(gè)好處。單元測試也有助于向?qū)彶檎哒f明組件應(yīng)該如何使用。
如果你的patch里包含了第三方代碼，請單獨(dú)提交。例如當(dāng)jQuery的9000行代碼被插入代碼中間時(shí)，要做好代碼審查工作就難上加難了。
寫出易于審查的代碼的最重要步驟之一是給你的代碼審查部分添加注釋。這表示你可以自己瀏覽審查部分，并在任何你覺得有助于審查者理解代碼意思的地方添加注釋。我發(fā)現(xiàn)這樣的注釋僅花費(fèi)相對較少的時(shí)間（經(jīng)常僅幾分鐘的時(shí)間）卻能產(chǎn)生巨大的作用，能讓代碼審查工作完成的更快、更好。當(dāng)然，代碼注釋也有許多相同的優(yōu)點(diǎn)，應(yīng)該在合適的地方使用，但是通常來說審查注釋更為明智。最后可以說是一個(gè)獎(jiǎng)勵(lì)吧， 研究表明，當(dāng)開發(fā)者重新閱讀和注釋代碼時(shí)，竟然發(fā)現(xiàn)他們自己的代碼里有很多的瑕疵。
龐大的代碼重構(gòu)
有時(shí)有必要重構(gòu)能影響許多組件的某個(gè)代碼庫。對于一個(gè)龐大的應(yīng)用程序，這個(gè)過程可能花費(fèi)好幾天（甚至更久）且導(dǎo)致龐大的補(bǔ)丁。在這些情況下一個(gè)標(biāo)準(zhǔn)的代碼審查工作可能是不切實(shí)際的。
最好的解決方法是遞增式重構(gòu)代碼。在工作代碼庫的合理范圍內(nèi)找到能達(dá)到你目的的某個(gè)改動(dòng)點(diǎn)。一旦改好了，review通過了，接著進(jìn)行下一個(gè)改動(dòng)，直到整個(gè)重構(gòu)工作完成。這個(gè)方法可能并不是每次都行得通，但是有想法和計(jì)劃，在重構(gòu)時(shí)要避免巨大的補(bǔ)丁通常是實(shí)際可行的。像這樣來重構(gòu)代碼可能要花開發(fā)人員更多的時(shí)間，但它同時(shí)也產(chǎn)生了更好的代碼質(zhì)量和更容易的審查工作。
如果真的實(shí)現(xiàn)不了遞增式重構(gòu)代碼（這可能要說一些關(guān)于如何寫好和組織好源代碼的事情），一個(gè)可能的解決方案是當(dāng)進(jìn)行重構(gòu)工作時(shí)用結(jié)對編程來代替代碼審查。
解決爭議
你的團(tuán)隊(duì)無疑是由一群聰明的專業(yè)人士組成。當(dāng)大家對某個(gè)確定的編碼問題觀點(diǎn)不同時(shí)，基本上都會(huì)產(chǎn)生爭議。作為一名開發(fā)人員，保持開放的心態(tài)，在你的審查者更傾向于一個(gè)不同的方法時(shí)要隨時(shí)準(zhǔn)備妥協(xié)。不要對你的代碼持專有的態(tài)度，也不要帶個(gè)人審查意見。如果僅僅是因?yàn)橛腥擞X得你應(yīng)該將一些重復(fù)的代碼重構(gòu)為一個(gè)可重復(fù)利用的函數(shù)時(shí)，這并不能表明你就不是一個(gè)有吸引力的、出色的和有魅力的人。
作為一個(gè)審查者，一定要機(jī)智。在改變建議之前，認(rèn)真考慮下是否你給的提議真的更好或僅僅只是你個(gè)人風(fēng)格問題。如果你選擇的戰(zhàn)場集中在一些源代碼中明顯需要改進(jìn)的區(qū)域，你將能獲得更多的成功。說一些諸如“考慮下……可能是值得的”或“有人建議……”的話更適合，而不是“連我的寵物倉鼠都能寫出一個(gè)比這更高效的排序算法”。
如果達(dá)不到一個(gè)中間立場（即雙方都不愿意妥協(xié)），那么就邀請一個(gè)雙方都尊敬的第三方開發(fā)人員過來看看，讓他們給出一些觀點(diǎn)和建議。
分享題目：代碼審查的實(shí)踐經(jīng)驗(yàn)
文章出自：http://fisionsoft.com.cn/article/dhsgdid.html
