我們時(shí)常會聽到團(tuán)隊(duì)成員說：

“這個(gè)項(xiàng)目搞代碼審查簡直是在浪費(fèi)時(shí)間。”

“我沒時(shí)間做代碼審查。”

“發(fā)布會延遲，是因?yàn)槲夷莻�(gè)卑鄙的同事還沒有審查過我的代碼。”

“你能相信我的同事居然要求我改我的代碼嗎？我這么優(yōu)雅完美的代碼哪里還需要改呢。”

　我們?yōu)槭裁匆�做代碼審查？

　　任何專業(yè)的軟件開發(fā)人員其最重要的目標(biāo)之一就是要不斷提高自己的工作質(zhì)量。但是只有團(tuán)隊(duì)協(xié)作才能力往一處使，勁往一處用，提高軟件質(zhì)量。代碼審查是實(shí)現(xiàn)這一目標(biāo)最重要的途徑之一。特別是，代碼審查可以：

• 從另一個(gè)角度發(fā)現(xiàn)缺陷和更好的解決辦法。
• 確保至少另外還有一人熟悉你的代碼。
• 通過翻閱資深開發(fā)人員的代碼，幫助培訓(xùn)新員工。
• 促進(jìn)知識共享。
• 激勵(lì)開發(fā)人員更好地寫代碼、解決代碼中的問題，以免在審查時(shí)被別人揪出來。

　代碼審查要徹底

　　然而，除非能實(shí)實(shí)在在徹徹底底地在代碼審查上花時(shí)間和精力，否則上述目標(biāo)是很難實(shí)現(xiàn)的。

　　我的看法是大概25％的原始開發(fā)時(shí)間應(yīng)該花在代碼審查上。舉個(gè)例子，如果一個(gè)開發(fā)人員需要用兩天時(shí)間來實(shí)現(xiàn)某個(gè)程式，那么就應(yīng)該花大約4小時(shí)進(jìn)行審查。

　　當(dāng)然時(shí)間并不是最重要的，關(guān)鍵是要看你能否正確審查代碼。你必須了解你正在審查的代碼。這意味著你不僅僅要知道它的的語法，還必須理解代碼是如何融入應(yīng)用程序這個(gè)大環(huán)境下，成為組件或庫的一部分。如果你不能把握每一行代碼的含義，那么你的審查就不到位，也不會非常有價(jià)值。這也是為什么良好執(zhí)行的代碼審查，大多不可能迅速被完成：因?yàn)槲覀冃枰獣r(shí)間來研究各種代碼，如能觸發(fā)給定功能以確保第三方API正確使用的代碼。

　　在審查時(shí)，除了要尋找代碼缺陷和其他問題，你還應(yīng)該確保：

• 囊括所有必要的測試。
• 已經(jīng)寫入了恰當(dāng)?shù)脑O(shè)計(jì)文檔。

　　即使是那些擅于寫測試和文檔的開發(fā)人員，也會在改變代碼的時(shí)候忘記更新。代碼評審時(shí)就應(yīng)該確保這些資料不會隨著時(shí)間而變得毫無用處。

　避免過度的代碼審查

　　開發(fā)人員應(yīng)該努力清空積壓的審查任務(wù)。有一種方法是在早上代碼審查，在開始自己的開發(fā)工作之前先搞定審查任務(wù)。當(dāng)然你也可以午飯前后或者是一天結(jié)束之時(shí)審查代碼。總而言之，你應(yīng)該將代碼當(dāng)作是日常工作的一部分，而不是工作的負(fù)累，所以你應(yīng)該避免：

• 沒有時(shí)間處理積壓的審查任務(wù)。
• 由于審查的沒有完成而導(dǎo)致了延遲發(fā)布。
• 傻乎乎地再去審查已經(jīng)不相干的代碼，在交給你之后已經(jīng)被改的面目全非。
• 因?yàn)闀r(shí)間緊迫急急忙忙地走個(gè)過場。

　編寫可審查的代碼

　　出現(xiàn)代碼積壓而失控的問題，審查人員并不是唯一一個(gè)需要負(fù)責(zé)的人。舉個(gè)例子，如果你的同事花了一周時(shí)間為一個(gè)大型程序添加了亂七八糟的代碼，那么發(fā)布的補(bǔ)丁就會變得很難審查，有太多的內(nèi)容需要理解和鉆研。甚至于連代碼目的和基本架構(gòu)都看得云里霧里。這是寫代碼的不是。

　　在編寫可審查的代碼之前，還需要做一些準(zhǔn)備。如果需要做一些棘手的架構(gòu)決策，那么最好和審查人員先討論一番。這將能讓你的代碼更容易審閱和理解，因?yàn)樗麄兲崆耙呀?jīng)知道你想實(shí)現(xiàn)什么以及計(jì)劃如何實(shí)現(xiàn)。這也可以避免，要是審查人員之后提出一個(gè)截然不同又更好的方法，而導(dǎo)致你不得不重寫一大片代碼的情況。

　　項(xiàng)目架構(gòu)應(yīng)該在設(shè)計(jì)文檔中詳細(xì)描述。這很重要，因?yàn)樗�能讓新的�?xiàng)目人員更快地理解現(xiàn)有的代碼庫，還能有助于審查人員更好地完成他們的工作。此外，單元測試能讓審查人員更好地理解各個(gè)組件的使用。

　　如果在你的補(bǔ)丁中還包含了第三方代碼，那么單獨(dú)提交。試想一下，要是代碼中間插進(jìn)去9000行jQuery，是不是大大增加了審查的難度！

　　創(chuàng)建可審查代碼最重要的步驟之一就是給你的代碼審查做注釋。這需要你自己預(yù)先審查過，然后在你認(rèn)為有助于審查人員理解的地方添加注釋。我發(fā)現(xiàn)，注釋后的代碼審查所需的時(shí)間相對較短（通常只需幾分鐘）。當(dāng)然，代碼注釋還是應(yīng)該酌情使用。此外，有研究表明，開發(fā)人員自己在給代碼注釋的時(shí)候也會發(fā)現(xiàn)許多存在的缺陷。

　代碼重構(gòu)

　　有時(shí)候，我們必須重構(gòu)代碼庫。如果恰巧碰到的是一個(gè)大型的應(yīng)用程序，那可能就會需要幾天的時(shí)間（甚至更多），同時(shí)會產(chǎn)生大量的補(bǔ)丁。在這種情況下，想要做到標(biāo)準(zhǔn)流程的代碼評審可能是不切實(shí)際的。

　　最好的解決辦法是逐步重構(gòu)代碼。先給定一個(gè)合理范圍，確定相應(yīng)的代碼庫，然后朝著目標(biāo)方向做整改和重構(gòu)。第一部分完成之后，審查并發(fā)布，然后進(jìn)行第二部分的重構(gòu)……，直到全部完成。這種階段式的方法可能并不總是可行的，但是如果我們在思考和規(guī)劃時(shí)使用這樣的方法，可以避免重構(gòu)時(shí)大規(guī)模的單片補(bǔ)丁。當(dāng)然這種方式可能需要的重構(gòu)時(shí)間更多，但是也會產(chǎn)出更高質(zhì)量的代碼，以及更加輕松的審查過程。

　　如果增量重構(gòu)代碼還是不可行，那么還有一個(gè)解決辦法就是結(jié)對編程。

　解決爭端

　　毫無疑問，團(tuán)隊(duì)中的每個(gè)成員都是人才，但是這也很容易導(dǎo)致在面對特定的編碼問題時(shí)，會出現(xiàn)意見分歧的情況。作為開發(fā)人員，我們應(yīng)該保持開放的態(tài)度，并且也要能虛心接受審查人員給出的不同意見。

　　而作為審查人員，說話要委婉。在提建議之前，先考慮一下你的意見是否真的更好或者僅僅只是因?yàn)槠肺恫煌�而已。如果你選擇的代碼區(qū)域確實(shí)需要改進(jìn)的，那么整個(gè)說服過程就會簡單得多。并且話要這樣講，“這里還值得考慮一下……”，“有人建議說……”，而不是“我閉著眼睛寫的算法也能比你的高效。”

　　當(dāng)然如果你們雙方都不肯妥協(xié)的話，可以要求你們都尊重的開發(fā)人員來看一看，給出他的意見。

　　英文原文：Practical Lessons in Peer Code Review 翻譯：codeceo

標(biāo)簽： 代碼

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請與原作者聯(lián)系。