敏捷開發(fā)中的Code Review

?

一些敏捷團(tuán)隊在實施敏捷開發(fā)中忙于編碼、忙于Unit?Test、忙于溝通、忙于Build等，雖然也有編碼審核階段，但大都浮于表面，流于形式，效果不佳。本文結(jié)合實踐，介紹筆者對敏捷開發(fā)中CodeReview的理解和相關(guān)經(jīng)驗

?

文/陳序明 黃彥軍

?

敏捷開 發(fā)中Code?Review的目的及內(nèi)容

做任何事情，首先要清晰為什么要做，才能有目標(biāo)和動力把事情做得更好，Code?Review?也是如此。只有清晰明確了敏捷團(tuán)隊進(jìn)行CodeReview?的動機(jī)，才能以此為方向開展后續(xù)工作。下面我們推薦的敏捷開發(fā)中常見的Code?Review的目的：

?

設(shè)計合理性Review

在筆者的另一篇文章中《敏捷開發(fā)中的架構(gòu)設(shè)計》談到，敏捷開發(fā)中崇尚Code?is?design，對開發(fā)人員提出了比以往更高的要求，即需要開發(fā)人員不斷地重構(gòu)出合理的設(shè)計。所以敏捷開發(fā)中的Code?Review也需要承擔(dān)一部分“結(jié)對設(shè)計”和“設(shè)計把關(guān)”的職責(zé)。

這部分的Code?Review?包括：設(shè)計的合理性（如實現(xiàn)方法，數(shù)據(jù)結(jié)構(gòu)，設(shè)計模式，擴(kuò)展性考慮等），是否存在大量重復(fù)代碼和其他組件是否有重復(fù)的代碼，包結(jié)構(gòu)設(shè)計是否合理等。

筆者了解的一些項目中，?進(jìn)行敏捷開發(fā)后，?提高了開發(fā)效率，?但是設(shè)計的質(zhì)量卻下降了。如Repeat Yourself?的現(xiàn)象（特別是跨組件之間的Repeat?Yourself?現(xiàn)象）；更有甚者，在筆者看到一個某銀行的應(yīng)用中（不是國內(nèi)的），數(shù)據(jù)庫連接和操作是直接在JSP中寫SQL語句。

像這些Bad?Design?的例子還是很多的。這些在重構(gòu)的時候應(yīng)該由開發(fā)人員解決。但考慮到不同開發(fā)人員之間技術(shù)功底不一，很有必要在Code Review階段進(jìn)行Review和討論。

互為Backup

這是很容易被忽略，但是又很重要的一個Code?Review的目的。

我們知道，敏捷開發(fā)中強(qiáng)調(diào)高質(zhì)量的代碼勝過詳細(xì)的文檔，所以某種程度上來說Code?is?Document。敏捷開發(fā)中的代碼承擔(dān)了一部分Document的職責(zé)，即傳遞技術(shù)的作用。

Code?Review?中，Review?的開發(fā)人員了解代碼的設(shè)計和實現(xiàn)，傳遞了技術(shù)，開發(fā)人員互為Backup，方便后期的維護(hù)，也減少了項目風(fēng)險。

?

分享知識、設(shè)計、技術(shù)

這也是很容易被忽略的一個很重要的目的。敏捷開發(fā)是一個中央集中控制到個體發(fā)揮積極性的過程，中央集中控制的優(yōu)點就是有統(tǒng)一的視圖和控制，經(jīng)常開大會，開長會，這樣知識和經(jīng)驗也較容易集中。敏捷開發(fā)中，分散在兩個Scrum?Team的開發(fā)人員之間，如果沒有好的機(jī)制，相互溝通也會相對較少，造成知識和好的經(jīng)驗無法在整個團(tuán)隊傳播。

筆者參加的項目中就碰到了類似情況，?當(dāng)時我們整個團(tuán)隊分成三個Scrum?Team，其中一個Scrum?Team負(fù)責(zé)一個Eclipse?工具的開發(fā)，?其中用到的一些功能和知識在其他ScrumTeam上以前都有涉及過。當(dāng)時負(fù)責(zé)開發(fā)的同事非常優(yōu)秀而且能力突出，但由于不知道其他Scrum?Team同事有這方面的經(jīng)驗，沒有很好地分享以往好的經(jīng)驗和知識，以至于最后導(dǎo)致浪費了一些學(xué)習(xí)的成本。

Code?Review是一個學(xué)習(xí)和享受的過程，一個開發(fā)人員的能力有限，而Code?Review正是這樣的一種機(jī)制，讓好的知識、設(shè)計在團(tuán)隊中分享，實現(xiàn)整體團(tuán)隊的成長和整體的效益最大化。

?

代碼可讀性

如上所說，敏捷開發(fā)中強(qiáng)調(diào)高質(zhì)量的代碼勝過冗余的文檔，所以Code某種程度上是Document。敏捷開發(fā)中，代碼的要求不止是能運行功能正確的代碼，而是有了更高的要求，即Code for?maintenance。

可維護(hù)的代碼，需要清晰，可讀性強(qiáng)，這里可讀性代碼檢查不是指代碼格式（代碼格式可以通過工具檢查出），而是指代碼語義。在筆者的文章《軟件可消費性設(shè)計》中有一些這方面的討論和建議。

?

Code中的“地雷區(qū)”Review

代碼中的邏輯，除了業(yè)務(wù)邏輯，還應(yīng)該包括技術(shù)邏輯。技術(shù)邏輯就是實現(xiàn)邏輯，?比如數(shù)據(jù)庫連接打開是否忘記關(guān)閉，是否正確使用線程，Exception?處理，密碼是否加密存儲等。

我把這些最常出現(xiàn)錯誤的地方，而且是測試不容易發(fā)現(xiàn)的地方，稱為Code中的“地雷區(qū)”。這些“地雷區(qū)”在Code?Review?中是值得花費一些時間進(jìn)行維護(hù)和檢查的。

建議，在整個團(tuán)隊中維護(hù)并共享“地雷區(qū)”注意事項列表，以及統(tǒng)一的處理方式和機(jī)制。并在編碼和Code?Review過程中都按照團(tuán)隊的最佳實踐進(jìn)行。

?

發(fā)現(xiàn)代碼中的業(yè)務(wù)邏輯錯誤

業(yè)務(wù)邏輯指的是代碼開發(fā)的功能是否符合業(yè)務(wù)需求，如一個加法函數(shù)，檢查其是否真的實現(xiàn)了加法的功能。

筆者了解的一些敏捷團(tuán)隊中，把發(fā)現(xiàn)代碼的業(yè)務(wù)邏輯錯誤當(dāng)做目標(biāo)和內(nèi)容，但往往效果都不是很好，基本都是從形式上泛泛檢查一番。原因有兩個：

1．業(yè)務(wù)邏輯的檢查是從需求到代碼的全方位檢查，需要花費大量時間，投入產(chǎn)出比失衡。

2．業(yè)務(wù)邏輯的檢查和業(yè)務(wù)需求緊密關(guān)聯(lián)，已經(jīng)超出了檢查人員的能力范圍（一般Code?Review是開發(fā)人員，不是業(yè)務(wù)人員）。

筆者認(rèn)為，發(fā)現(xiàn)邏輯錯誤，不應(yīng)該是Code?Review?的目的和內(nèi)容。應(yīng)該是Unit?Test，功能測試，集成測試的目的。從投入產(chǎn)出比考慮，不應(yīng)該花費太多時間在Code?Review?階段去進(jìn)行邏輯錯誤檢查。

?

敏捷開發(fā)中不推薦的Code Review的目的及內(nèi)容

下面還有一些常見的Code?Review目的和內(nèi)容被很多團(tuán)隊廣泛使用，但作者認(rèn)為這些并不是敏捷開發(fā)中的主要目的和內(nèi)容，團(tuán)隊?wèi)?yīng)該把時間花費在重要的目的和內(nèi)容上，而不應(yīng)該投入精力在下面的這些Code?Review目的和內(nèi)容上。

?

發(fā)現(xiàn)性能問題

有些團(tuán)隊把性能問題，也作為Code Review的目的和內(nèi)容之一，然后提出一些如String應(yīng)該使用StringBuilder，而不能使用+，類似這樣的看似有用其實無用建議。

筆者認(rèn)為，性能問題是需要量化的衡量和精確定位，?很難通過Code Review檢查出來。而一些粗淺的性能問題可以通過一些工具方便地掃描出來，而無須花費時間去進(jìn)行Code?Review。

如圖1是RAD?V7.0?(IBM?Rati?onal Application?Developer)?中的Software Analyzer工具帶有的Performance檢查：

圖1 RAD Software Analyzer中的Performance檢查

所以筆者認(rèn)為，開發(fā)人員提交的代碼，需要是經(jīng)過工具檢查后的代碼。而代碼審核人員則無須花費時間在性能相關(guān)的Code?Review?上。具體的性能問題交給性能測試。

?

發(fā)現(xiàn)開源的授權(quán)法律問題

開源軟件也可以借助一些檢查工具，?統(tǒng)一通過工具掃描，?無需在Code?Review?階段花費時間。

?

其他問題，如國際化，J2EE?Best Practice等

這些問題開發(fā)人員可以在提交代碼之前通過工具發(fā)現(xiàn)和解決，?不是Code?Review?階段的職責(zé)和目的，也無須花費時間去處理。

像FindBugs?和RAD?這樣的工具就具備類似的代碼檢查功能，如RADV7.0?中的Software?Analyzer?工具帶有如下的檢查功能：

圖2 RAD Software Analyzer中檢查規(guī)則列表

1．設(shè)計原則（5）：用于面向?qū)ο缶幊痰脑O(shè)計原則的規(guī)則。

2．全球化（47）：基于全球化編碼最佳實踐的規(guī)則，有助于確保代碼在局部環(huán)境中正確地運行。

3．J2EE?最佳實踐（32）：基于最佳的?Java??2?Platform?Enterprise Edition（?J2EE）開發(fā)實踐的規(guī)則，以及支持瞄準(zhǔn)?IBM??WebSphere??服務(wù)的Web?項目的規(guī)則；

4．J2EE?安全性（17）：驗證代碼符合?J2EE?技術(shù)安全性需要的規(guī)則；

5．J2SE?最佳實踐（71）：基于最佳的?Java?2?Platform?Standard?Edition （J2SE）開發(fā)實踐的規(guī)則；

6．J2SE?安全性（9）：驗證代碼符合?J2SE?技術(shù)安全性需要的規(guī)則；

7．命名（2）：關(guān)于?Java?代碼中命名約定的規(guī)則；

8．性能（26）：加強(qiáng)在?Java?應(yīng)用程序中提高性能和減少存儲器足跡的建議的規(guī)則；

9．私有?API?（3）：定位那些不屬于?Java?代碼的?API?的規(guī)則。

?

敏捷開發(fā)中如何開展Code Review

在清晰明確了敏捷團(tuán)隊進(jìn)行Code Review?的目的和內(nèi)容后，下面介紹如何有效地開展Code?Review。

?

溝通、協(xié)作、互助、學(xué)習(xí)的團(tuán)隊氛圍

Code?Review?中，Review?人員和開發(fā)人員不是對立的關(guān)系，而是互助、溝通、協(xié)作和學(xué)習(xí)的過程。團(tuán)隊形成互助、互學(xué)的氣氛，既能互相增長團(tuán)隊的知識和經(jīng)驗，還能把產(chǎn)品做得更好。

Code?Review協(xié)作過程：

a）先由代碼的開發(fā)人員向檢查人員進(jìn)行大體的介紹，包括設(shè)計思想、數(shù)據(jù)結(jié)構(gòu)、程序代碼結(jié)構(gòu)介紹等。

b）雙方進(jìn)行討論、交流。

c）檢查人員單獨進(jìn)一步進(jìn)行Code Review，并記錄Review結(jié)果和建議。

d）由檢查人員和開發(fā)人員一起，檢查人員反饋Code?Review結(jié)果，并和開發(fā)人員一起討論改進(jìn)方法，重構(gòu)。

e）最后把可重用的Code?Review的經(jīng)驗總結(jié)編碼規(guī)范，或者記錄到“地雷區(qū)”中。便于整個團(tuán)隊復(fù)用經(jīng)驗。

圖3 Code Review是溝通、協(xié)作、互助和學(xué)習(xí)的過程

開展以上過程可以以開發(fā)人員為主，輔助以工具。但無須規(guī)定系列的文檔、流程、Check?List?等，這反而會影響開發(fā)人員的積極性。

Code?Review是發(fā)現(xiàn)問題的過程，同時也是學(xué)習(xí)和交流過程。需要是靈活、自由、主動的態(tài)度，而不是行政上的控制和規(guī)章流程。筆者建議：和敏捷開發(fā)的核心思想一致，讓團(tuán)隊明確Code?Review?的思想、作用和目的內(nèi)容后，充分發(fā)揮個體的積極性和學(xué)習(xí)分享的動力。隨時隨地地進(jìn)行Code Review，討論，重構(gòu)，改進(jìn)。

?

增量式Review

大家都知道，軟件開發(fā)中存在長鞭效應(yīng)，即一個問題越在后期發(fā)現(xiàn)造成的影響會越大，Code?Review?也是

如此，如圖4所示：

?

圖 4 Code Review中的長鞭效應(yīng)

軟件的開發(fā)過程中，?應(yīng)該階段性地進(jìn)行Code Review，而不是等到所有代碼都開發(fā)完畢后再做一次性的Code?Review。那時如果發(fā)現(xiàn)問題，造成的改動成本比增量式的檢查來的大得多。

筆者了解的一些開發(fā)團(tuán)隊，他們在軟件開發(fā)完畢，并測試后，才臨時確定Code?Review的人員，然后再安排半天左右的時間進(jìn)行Code?Review。結(jié)果盡管發(fā)現(xiàn)一些結(jié)構(gòu)或設(shè)計方面問題，但由于修改成本大，也無法進(jìn)行改進(jìn)。

正確的方式是，在早期就參與設(shè)計開發(fā)過程，抱著互助、溝通、協(xié)作、學(xué)習(xí)的思想，階段性的參與討論、學(xué)習(xí)并貢獻(xiàn)自己的意見。具體Review的頻率、次數(shù)則可以由開發(fā)人員抱著主動、積極的態(tài)度，按照敏捷的思想自己去把握決定。

?

利用工具進(jìn)行Code?Inspection

有很多的工具可以輔助Code Review?：

1．如代碼格式檢查Checkstyle?工具，檢查如過大的類、太長的方法和未使用的變量等這樣違反編程規(guī)范的問題。

2．RAD中的Software?Analyzer工具，可以基于規(guī)則進(jìn)行國際化、J2EE最佳實踐、性能、安全等檢查。3．CSAR，用于掃描代碼檢查開源軟件等。

4．JDepend，可以檢查包依賴關(guān)系。

5．CPD工具，Eclipse?的?PMD?插件提供了一項叫做?CPD（或復(fù)制粘貼探測器）的功能，用于尋找重復(fù)的代碼。

6．Eclipse?的Metrics?插件，提供了很多有效地查出代碼復(fù)雜度的功能。

輔助以工具和自動化流程，能花很少時間輕松完成很多基本的Code Inspection?工作。讓團(tuán)隊有更多的時間和精力去做更重要的Code?Review。

?

持續(xù)自動化Code?Inspection

工具檢查可以由開發(fā)人員自行檢查并修正，?但一種更可持續(xù)的做法是自動化的集成工具進(jìn)行Code Inspection，可以通過自動化腳本在每日進(jìn)行Build?前進(jìn)行掃描，并呈現(xiàn)報告給相應(yīng)人員。

?

Code?Review協(xié)作工具

為了快速有效地進(jìn)行人工Code Review協(xié)作，可以使用諸如Jupiter這樣的工具輔助進(jìn)行?？梢詭椭_發(fā)人員有效管理Code?Review任務(wù)、問題、建議等。

?

總結(jié)

Code?Review?的核心是：互助，溝通，協(xié)作，學(xué)習(xí)的過程，這是一個美妙而享受的過程，是跨越需求分析、架構(gòu)設(shè)計、編碼等各階段的過程。敏捷團(tuán)隊?wèi)?yīng)該統(tǒng)一達(dá)成Code?Review?對產(chǎn)品、對團(tuán)隊、對個人的巨大好處的共識，發(fā)揮出個體的積極性，相信會改變“流于形式”的現(xiàn)狀，發(fā)揮Code Review巨大的威力。

?

作者簡介：

陳序明，IBM公司顧問軟件工程師。他目前在IBM中國北京研發(fā)中心工作，從事銀行多渠道整合（網(wǎng)上銀行、手機(jī)銀行、柜面等）方面的開發(fā)和研究，對軟件架構(gòu)、敏捷開發(fā)、產(chǎn)品管理和銀行業(yè)務(wù)很感興趣。

黃彥軍，IBM中國軟件研發(fā)中心軟件工程師，2008年在西安電子科技大學(xué)獲得計算機(jī)系統(tǒng)結(jié)構(gòu)碩士學(xué)位。目前主要從事中間件、Eclipse插件開發(fā)，深入理解C、C++、Java。感興趣的技術(shù)領(lǐng)域包括：分布式計算，網(wǎng)絡(luò)應(yīng)用等。

（本文來自《程序員》雜志0912期）

from:http://www.programmer.com.cn/1310/

轉(zhuǎn)載于:https://www.cnblogs.com/dkblog/archive/2011/07/18/2109779.html

總結(jié)

以上是生活随笔為你收集整理的敏捷开发中的Code Review的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。