代碼審查(CodeReview)

《代碼審查(CodeReview)》由會員分享，可在線閱讀，更多相關(guān)《代碼審查(CodeReview)（14頁珍藏版）》請?jiān)谘b配圖網(wǎng)上搜索。

1、代碼審查(Code Review) 一、概述 代碼審查（Code Review)是軟件開發(fā)中常用的手段，和QA測試相比，它更容易發(fā)現(xiàn)和架構(gòu)以及時序相關(guān)等較難發(fā)現(xiàn)的問題，還可以幫助團(tuán)隊(duì)成員提高編程技能，統(tǒng)一編程風(fēng)格等，目前監(jiān)控團(tuán)隊(duì)雖然提倡代碼審查，也有相關(guān)的輔助工具，但是一直沒有真正的推行起來，這半年的時間里，一些線上的bug如果經(jīng)過代碼審查，基本上可以避免的，大家也逐漸認(rèn)識到代碼審查可以有效地提高代碼質(zhì)量。 二、代碼審查的作用 1、提高代碼質(zhì)量。 通過代碼審查來發(fā)現(xiàn)bug及代碼中的不規(guī)范，這是不容置疑的，通過代碼審查，代碼將更加整潔，有更好

2、的注釋，更好的程序結(jié)構(gòu)。 2、提高開發(fā)者開發(fā)水平。 開發(fā)者知道自己編寫的代碼會被同事審查，將會更加認(rèn)真的編寫代碼，也將會督促開者不斷地學(xué)習(xí)、向有經(jīng)驗(yàn)的同事請教。 3、提高程序的可維護(hù)性。 一份程序代碼將會有更多的同事熟悉，更好的代碼質(zhì)量，自然地也增加程序的可維護(hù)性。 4、提高開發(fā)者的對編碼的責(zé)任感。 如果你在編程，而且知道將會有同事檢查你的代碼，你編程態(tài)度就完全不一樣了。你寫出的代碼將更加整潔，有更好的注釋，更好的程序結(jié)構(gòu)——因?yàn)槟阒溃莻€你很在意的人將會查看你的程序。沒有代碼審查，你知道人們最終還是會看你的

3、程序。但這種事情不是立即發(fā)生的事，它不會給你帶來同等的緊迫感，它不會給你相同的個人評判的那種感受。 5、傳播知識 在很多的開發(fā)團(tuán)隊(duì)里，經(jīng)常每一個人負(fù)責(zé)一個核心模塊，每個人都只關(guān)注他自己的那個模塊。除非是同事的模塊影響了自己的程序，他們從不相互交流。這種情況的后果是，每個模塊只有一個人熟悉里面的代碼。如果這個人休假或——但愿不是——辭職了，其他人則束手無策。通過代碼審查，至少會有兩個人熟悉這些程序——作者，以及審查者。審查者并不能像程序的作者一樣對程序十分了解——但他會熟悉程序的設(shè)計(jì)和架構(gòu)，這是極其重要的。 三、代碼審查的執(zhí)行障礙 1、缺少代碼審查的標(biāo)準(zhǔn)

4、 缺少代碼審查的標(biāo)準(zhǔn)，往往審查人員習(xí)慣性地根據(jù)自身開發(fā)經(jīng)驗(yàn)去進(jìn)行代碼審查，容易變成去挑毛病，找bug，容易產(chǎn)生不良地影響。 2、資深開發(fā)人員的較少，工作過多，缺少代碼審查的時間安排 在一個小規(guī)模團(tuán)隊(duì)里，資深的同事總是忙不過來，因?yàn)楹诵牡墓ぷ鞫荚诘戎?，資深的開發(fā)人員少，代碼審查的質(zhì)量自然上不去。 3、團(tuán)隊(duì)成員的技術(shù)差距過大 一個團(tuán)隊(duì)中往往有不少經(jīng)驗(yàn)較淺的開發(fā)人員，當(dāng)然編碼水平也就相對較差，如果缺少有效的激勵手段，往往資深的開發(fā)人員是比較討厭經(jīng)常去審查經(jīng)驗(yàn)很淺的開發(fā)人員的代碼。 四、代碼審查的實(shí)踐要素。 雖然代碼審查是一個被廣泛采納的實(shí)踐，但是

5、由于存在很多的實(shí)踐方式，所以開發(fā)團(tuán)隊(duì)經(jīng)常搞不清楚它的最佳實(shí)踐是什么樣的，正確的代碼審查應(yīng)該重點(diǎn)考慮的幾個因素有以下幾點(diǎn)。 1、人員結(jié)構(gòu) 在你的團(tuán)隊(duì)中有多少同事?lián)碛凶銐虻膶I(yè)技能來擔(dān)當(dāng)合格的代碼審查者？作者曾經(jīng)和多個開發(fā)團(tuán)隊(duì)溝通過，這些團(tuán)隊(duì)都聲稱本身只有一個資深的開發(fā)人員，如果讓他來負(fù)責(zé)所有的代碼審查工作，那么團(tuán)隊(duì)的核心開發(fā)就無法開展了。作者也遇到過類似的情況。在一個小規(guī)模團(tuán)隊(duì)里，資深的同事總是忙不過來，因?yàn)楹诵牡墓ぷ鞫荚诘戎觥? 2、地理位置 你的團(tuán)隊(duì)成員是如何分布的？他們是否是分散在世界各地還是坐在同一個敞亮的辦公室里？ 代碼審查需要精力的專注和反饋，如果開發(fā)

6、人員能夠面對面的溝通，那么審查工作會便于實(shí)施。而物理隔離的遠(yuǎn)程團(tuán)隊(duì)很難達(dá)到代碼審查的滿意結(jié)果。 3、所在領(lǐng)域 你所在的IT領(lǐng)域需要遵守怎樣的規(guī)則和約束呢？如果你在一個受到嚴(yán)格監(jiān)管的行業(yè)，那么你必須遵循有關(guān)審計(jì)和報(bào)告的規(guī)則，這意味著你必須想辦法跟蹤代碼審查的頻率和質(zhì)量。如果所在的領(lǐng)域把安全性作為重點(diǎn)，那么可能在代碼審查過程中要引入安全審計(jì)。 4、復(fù)雜性 你的代碼復(fù)雜性如何？在代碼審查時，需要多個不同專業(yè)技能的審查者嗎？例如，游戲開發(fā)可能會引入非常復(fù)雜的業(yè)務(wù)邏輯來處理文字交互和場景跟蹤，同時還需要特定的動畫處理和內(nèi)存管理技術(shù)。在審查如此復(fù)雜的代碼時，應(yīng)該引入多個審查者

7、從不同角度來檢閱代碼的質(zhì)量。 而且在許多情況下，不同的項(xiàng)目有不同的需求——存在多個團(tuán)隊(duì)構(gòu)建應(yīng)用，需要不同的配置文件。這里有一些技巧可以幫助你改進(jìn)代碼審查過程的工具并解決一些可能會面臨的問題： A.促進(jìn)溝通 任何審查過程，不論是代碼還是文檔還是績效，最好是面對面進(jìn)行。在你使用工具做完代碼審查之后，與相應(yīng)的開發(fā)人員約個時間做口頭的反饋。如果你們不在同一地區(qū)，可以利用視頻或者電話來進(jìn)行溝通，但是這種溝通是必要的，你可以以此作為協(xié)作和指導(dǎo)的一種手段。 B.利用專業(yè)技能 如果被審查的代碼與其他代碼領(lǐng)域存在關(guān)聯(lián)，或者對安全、性能、可擴(kuò)展性等方面存在一定的影響，你可能無法

8、只安排一個人來完成審查工作。你需要多個人來查看代碼以確保所有可能的后果都被考慮在內(nèi)。在這種情況下，最好找到一個工具來協(xié)助多個人完成審查工作。該工具的作用包括指定哪個人審查哪個角度并把相應(yīng)的代碼展現(xiàn)出來，而且還可以保存審查人員的注解。 C. 公開審查意見 審查工具的優(yōu)點(diǎn)之一是多人可以集中地審查相同的代碼。把所有人叫到一個屋子里做團(tuán)隊(duì)審查非常不利于大家考慮各個不同的方面。但是工具可以幫助你讓大家分別查看代碼并把所有的意見集中起來： · 避免意見重復(fù)，如果別人已經(jīng)發(fā)表了類似的看法，那么后面的人就不用記錄了。 · 團(tuán)隊(duì)學(xué)習(xí)，通過查看別人的意見能夠?qū)W習(xí)其他人的思維角度和專業(yè)領(lǐng)域。 ·

9、監(jiān)督審查過程。 五、代碼審查的一些常用經(jīng)驗(yàn)與注意事項(xiàng)。 1.代碼審查要求團(tuán)隊(duì)有良好的文化 　　團(tuán)隊(duì)需要認(rèn)識到代碼審查是為了提高整個團(tuán)隊(duì)的能力，而不是針對個體設(shè)置的檢查“關(guān)卡”。 　　“A的代碼有個bug被B發(fā)現(xiàn)，所以A能力不行，B能力更好”，這一類的陷阱很容易被擴(kuò)散從而影響團(tuán)隊(duì)內(nèi)部的協(xié)作，因此需要避免。 　　另外，代碼審查本身可以提高開發(fā)者的能力，讓其從自身犯過的錯誤中學(xué)習(xí)，從他人的思路中學(xué)習(xí)。如果開發(fā)者對這個流程有抵觸或者反感，這個目的就達(dá)不到。 2.謹(jǐn)慎的使用審查中問題的發(fā)現(xiàn)率作為考評標(biāo)準(zhǔn) 　　在代碼審查中如果發(fā)現(xiàn)問題，對于問題的發(fā)現(xiàn)者來說這是好事，應(yīng)該予以鼓勵。但對于被發(fā)現(xiàn)

10、者，我們不主張使用這個方式予以懲罰。軟件開發(fā)中bug在所難免，過度苛求本身有悖常理。更糟的是，如果造成參與者怕承擔(dān)責(zé)任，不愿意在審查中指出問題，代碼審查就沒有任何的價(jià)值和意義。 3.控制每次審查的代碼數(shù)量 　　根據(jù)smartbear在思科所作的調(diào)查，每次審查200行-400行的代碼效果最好。每次試圖審查的代碼過多，發(fā)現(xiàn)問題的能力就會下降， 　　我們在實(shí)踐中發(fā)現(xiàn)，隨著開發(fā)平臺和開發(fā)語言的不同，最優(yōu)的代碼審查量有所不同。但是限制每次審查的數(shù)量確實(shí)非常必要，因?yàn)檫@個過程是高強(qiáng)度的腦力密集型活動。時間一長，代碼在審查者眼里只是字母，無任何邏輯聯(lián)系，自然不會有太多的產(chǎn)出。 4.帶著問題去進(jìn)行審查

11、　　我們在每次代碼審查中，要求審查者利用自身的經(jīng)驗(yàn)先思考可能會碰到的問題，然后通過審查工作驗(yàn)證這些問題是否已經(jīng)解決。一個竅門是，從用戶可見的功能出發(fā)，假設(shè)一個比較復(fù)雜的使用場景，在代碼閱讀中驗(yàn)證這個使用場景是否能夠正確工作。 　　使用這個技巧，可以讓審查者有代入感，真正的沉浸入代碼中，提高效率。大家都知道看武俠小說不容易瞌睡，而看專業(yè)書容易瞌睡，原因就是武俠小說更容易產(chǎn)生代入感。 　　有的研究建議每次樹立目標(biāo)，控制單位時間內(nèi)審核的代碼數(shù)量。這個方法在我們的實(shí)踐中顯得很機(jī)械和流程化，不如上面的方法效果好。 5.所有的問題和修改，必須由原作者進(jìn)行確認(rèn) 　　如果在審查中發(fā)現(xiàn)問題，務(wù)必由原作者進(jìn)

12、行確認(rèn)。 　　這樣做有兩個目的： 　　(1)確認(rèn)問題確實(shí)存在，保證問題被解決 　　(2)讓原作者了解問題和不足，幫助其成長 　　有些時候?yàn)榱俗非笮剩薪?jīng)驗(yàn)的審查者更傾向于直接修改代碼乃至重構(gòu)所有代碼，但這樣不利于提高團(tuán)隊(duì)效率，并且會增加因?yàn)橹貥?gòu)引入新bug的幾率，通常情況下我們不予鼓勵。 6.利用代碼審查激活個體 “能動性 "　　即使項(xiàng)目進(jìn)度比較緊張，無法完全的進(jìn)行代碼審查，至少也要進(jìn)行部分代碼的審查，此時隨即抽取一些關(guān)鍵部分是個不錯的辦法。 　　背后的邏輯是，軟件開發(fā)是非常有創(chuàng)造性的工作，開發(fā)者都有強(qiáng)烈的自我驅(qū)動性和自我實(shí)現(xiàn)的要求。讓開發(fā)者知道他寫的任何代碼都可能被其他人閱讀和

13、審察，可以促使開發(fā)者集中注意力，尤其是避免將質(zhì)量糟糕，乃至有低級錯誤的代碼提交給同伴審查。開源軟件也很好的利用了這種心態(tài)來提高代碼質(zhì)量。 7.在非正式，輕松的環(huán)境下進(jìn)行代碼審查 　　如前所述，代碼審查是一個腦力密集型的工作。參與者需要在比較輕松的環(huán)境下進(jìn)行該工作。因此，我們認(rèn)為像某些實(shí)踐中建議的那樣，以會議的形式進(jìn)行代碼審查效果并不好，不僅因?yàn)殚L時間的會議容易讓效率低下，更因?yàn)闀h上可能出現(xiàn)的爭議和思考不利于進(jìn)行如此復(fù)雜的工作。 8.提交代碼前自我審查，添加對代碼的說明 　　所有團(tuán)隊(duì)成員在提交代碼給其他成員審查前，必須先進(jìn)行一次審查。這次自我修正形式的審查除了檢查代碼的正確性以外，還可以完

14、成如下的工作： 　　(1)對代碼添加注釋，說明本次修改背后的原因，方便其他人進(jìn)行審查。 　　(2)修正編碼風(fēng)格，尤其是一些關(guān)鍵數(shù)據(jù)結(jié)構(gòu)和方法的命名，提高代碼的可讀性。 　　(3)從全局審視設(shè)計(jì)，是否完整的考慮了所有情景。在實(shí)現(xiàn)之前做的設(shè)計(jì)如果存在考慮不周的情況，這個階段可以很好的進(jìn)行補(bǔ)救。 　　我們在實(shí)踐中發(fā)現(xiàn)，即使只有原作者進(jìn)行代碼審查，仍然可以很好的提高代碼質(zhì)量。 9.實(shí)現(xiàn)中記錄筆記可以很好的提高問題發(fā)現(xiàn)率 　　成員在編碼的時候應(yīng)做隨手記錄，包括在代碼中用注釋的方式表示，或者記錄簡單的個人文檔，這樣做有幾個好處： 　　(1)避免遺漏。在編碼時將考慮到的任何問題都記錄下來，在審查

15、階段再次檢查這些問題都確認(rèn)解決。 　　(2)根據(jù)研究，每個人都習(xí)慣犯一些重復(fù)性的錯誤。這類問題在編碼是記錄下來，可以在審查的時候用作檢查的依據(jù)。 　　(3)在反復(fù)記錄筆記并在審查中發(fā)現(xiàn)類似的問題后，該類問題出現(xiàn)率會顯著下降 10.使用好的工具進(jìn)行輕量級的代碼審查 比如利用findbug進(jìn)行代碼掃描。 六、實(shí)現(xiàn)代碼審查的前提條件 （一）、審查制度的執(zhí)行前提 1、代碼審查必須是基本制度，是工作中一部分。 2、在團(tuán)隊(duì)中需要有一份大家接受的代碼規(guī)范文檔。 3、與業(yè)務(wù)需求相關(guān)的代碼修改，需要審查代碼的同事熟悉業(yè)務(wù)需求，參與設(shè)計(jì)評審，不熟悉需求是不能有效地審查代碼

16、。 4、代碼審查是工作中的一部分，需要安排一定的時間來進(jìn)行，這需要領(lǐng)導(dǎo)在工作安排中合理安排時間。 （二）、代碼審查的執(zhí)行前提 1、Code Review人員是否理解了Code Review的概念和Code Review將做什么 如果做Code Review的人員不能理解Code Review對項(xiàng)目成敗和代碼質(zhì)量的重要程度，他們的做法可能就會是應(yīng)付了事。 2、代碼是否已經(jīng)正確的build，build的目的使得代碼已經(jīng)不存在基本語法錯誤 我們總不希望高級開發(fā)人員或是主管將時間浪費(fèi)在檢查連編譯都通不過的代碼上吧。 3、代碼執(zhí)行時功能是否正確 Code

17、 Review人員也不負(fù)責(zé)檢查代碼的功能是否正確，也就是說，需要復(fù)查的代碼必須由開發(fā)人員或質(zhì)量人員負(fù)責(zé)該代碼的功能的正確性。 4、Review人員是否理解了代碼 做復(fù)查的人員需要對該代碼有一個基本的了解，其功能是什么，是拿一方面的代碼，涉及到數(shù)據(jù)庫或是通訊，這樣才能采取針對性的檢查 5、開發(fā)人員是否對代碼做了單元測試 這一點(diǎn)也是為了保證Code Review前一些語法和功能問題已經(jīng)得到解決，Code Review人員可以將精力集中在代碼的質(zhì)量上。 七、代碼審查需要做什么 Code Review主要檢查代碼中是否存在以下方面問題： 代碼的一致性、編碼風(fēng)格、代碼的

18、安全問題、代碼冗余、是否正確設(shè)計(jì)以滿足需求（性能、功能）等等 1完整性檢查 代碼是否完全實(shí)現(xiàn)了設(shè)計(jì)文檔中提出的功能需求 代碼是否已按照設(shè)計(jì)文檔進(jìn)行了集成和Debug 代碼是否已創(chuàng)建了需要的數(shù)據(jù)庫，包括正確的初始化數(shù)據(jù) 代碼中是否存在任何沒有定義或沒有引用到的變量、常數(shù)或數(shù)據(jù)類型 2 一致性檢查 代碼的邏輯是否符合設(shè)計(jì)文檔 代碼中使用的格式、符號、結(jié)構(gòu)等風(fēng)格是否保持一致 3 正確性檢查 代碼是否符合制定的標(biāo)準(zhǔn) 所有的變量都被正確定義和使用 所有的注釋都是準(zhǔn)確的 所有的程序調(diào)用都使用了正確的參數(shù)個數(shù) 4 可修改性檢查 代碼涉及到的常量是否易于修改(如使用配置、

19、定義為類常量、使用專門的常量類等) 代碼中是否包含了交叉說明或數(shù)據(jù)字典，以描述程序是如何對變量和常量進(jìn)行訪問的 代碼是否只有一個出口和一個入口（嚴(yán)重的異常處理除外） 5 可預(yù)測性檢查 代碼所用的開發(fā)語言是否具有定義良好的語法和語義 是否代碼避免了依賴于開發(fā)語言缺省提供的功能 代碼是否無意中陷入了死循環(huán) 代碼是否是否避免了無窮遞歸 6 健壯性檢查 代碼是否采取措施避免運(yùn)行時錯誤（如數(shù)組邊界溢出、被零除、值越界、堆棧溢出等） 7 結(jié)構(gòu)性檢查 程序的每個功能是否都作為一個可辯識的代碼塊存在 循環(huán)是否只有一個入口 8 可追溯性檢查 代碼是否對每個程序進(jìn)行了唯一標(biāo)識

20、 是否有一個交叉引用的框架可以用來在代碼和開發(fā)文檔之間相互對應(yīng) 代碼是否包括一個修訂歷史記錄，記錄中對代碼的修改和原因都有記錄 是否所有的安全功能都有標(biāo)識 9 可理解性檢查 注釋是否足夠清晰的描述每個子程序 是否使用到不明確或不必要的復(fù)雜代碼，它們是否被清楚的注釋 使用一些統(tǒng)一的格式化技巧（如縮進(jìn)、空白等）用來增強(qiáng)代碼的清晰度 是否在定義命名規(guī)則時采用了便于記憶，反映類型等方法 每個變量都定義了合法的取值范圍 代碼中的算法是否符合開發(fā)文檔中描述的數(shù)學(xué)模型 10可驗(yàn)證性檢查 代碼中的實(shí)現(xiàn)技術(shù)是否便于測試 八、代碼審查的流程。 1、在開發(fā)之前就需要確認(rèn)誰

21、來進(jìn)行代碼審查，單個還是多個審查人，確定代碼審查的方式（review board，面談討論溝通）。 2、確定好審查人后需要讓相應(yīng)的審查人員參與熟悉開發(fā)的功能需求（業(yè)務(wù)需求、性能需求）是什么，以便讓審查人知道需要審查的代碼實(shí)現(xiàn)的功能包含那些要點(diǎn)，在實(shí)際的工作中以需求討論、設(shè)計(jì)評審來完成審查人員對需求與設(shè)計(jì)的熟悉。 3、開發(fā)完成后提交到review board中通知代碼審查人進(jìn)行代碼審查，代碼審查人如果發(fā)現(xiàn)有需要代碼中有需要修改的地方，在review board中寫下原因反饋給開發(fā)人員，開發(fā)人員按要求進(jìn)行代碼修改后再度提交到review board，繼續(xù)進(jìn)行代碼審查，直至審查通過。