敏捷開發(fā)中高質(zhì)量Java代碼開發(fā)實(shí)踐

1、本文將介紹在敏捷開發(fā)過程中如何通過采取一系列的步驟來保證和提高整個項目的代碼質(zhì)量，闡述了每一步可以利用的工具和最佳實(shí)踐，從而使開發(fā)過程更加規(guī)范化，成就高質(zhì)量的代碼。概述Java項目開發(fā)過程中，由于開發(fā)人員的經(jīng)驗、代碼風(fēng)格各不相同，以及缺乏統(tǒng)一的標(biāo)準(zhǔn)和管理流程，往往導(dǎo)致整個項目的代碼質(zhì)量較差，難于維護(hù)，需要較大的測試投入和周期等問題。這些問題在一個項目組初建、需求和設(shè)計均具有不完全可預(yù)期性和完備性的全新項目中將尤為突出。本文將結(jié)合敏捷開發(fā)周期短，變化快等特點(diǎn)，介紹如何通過在開發(fā)過程中采取一系列步驟來保證和提高整個開發(fā)團(tuán)隊的代碼質(zhì)量，并闡述了每一步可以利用的工具和最佳實(shí)踐，從而使開發(fā)過程更加規(guī)范化

2、，成就高質(zhì)量的代碼，減少測試的投入，并促進(jìn)整個團(tuán)隊的技能提高，最終提高開發(fā)效率和質(zhì)量。如圖1所示，敏捷開發(fā)過程經(jīng)歷需求調(diào)研，用例分析和用例分解，進(jìn)入開發(fā)迭代階段。在每個迭代過程中，可以采用以下五個步驟來保證和提高整個項目的代碼質(zhì)量：統(tǒng)一編碼規(guī)范、代碼樣式；靜態(tài)代碼分析(staticcodereview)；單元測試；持續(xù)集成；代碼評審和重構(gòu)(Review&Refactor)。下文將針對每個步驟和其所使用的工具、方法進(jìn)行詳細(xì)描述。圖1.敏捷開發(fā)中的Java代碼質(zhì)量保證步驟代碼質(zhì)量保證步驟步驟一：統(tǒng)一編碼規(guī)范、代碼樣式規(guī)范統(tǒng)一的編碼會增加項目代碼的可讀性和可維護(hù)性，但實(shí)際情況往往是項目組內(nèi)的

3、Java代碼開發(fā)人員的編碼風(fēng)格常常各不相同，這可能是由于不同的經(jīng)驗習(xí)慣或者缺乏編碼規(guī)范方面的學(xué)習(xí)造成的。這樣一來，其他項目成員或者維護(hù)人員在閱讀項目代碼時就需要花費(fèi)更多的時間來理解代碼作者的意圖，所以制定并采取統(tǒng)一的編碼規(guī)范就顯得很重要。編碼規(guī)范主要應(yīng)包含以下幾個方面： 一般規(guī)則和格式規(guī)范。例如代碼縮進(jìn)、程序塊規(guī)范、每行最大代碼長度等。 命名規(guī)則。例如包名、類名、變量、方法、接口、參數(shù)等命名規(guī)范 文檔規(guī)范。例如類文件頭聲明、類注釋、成員變量和方法注釋等規(guī)范。 編程規(guī)范。例如異常、并發(fā)、多線程等方面的處理方式。 其他規(guī)范。例如日志格式、屬性文件格式，返回值和消息格式。項目的編碼規(guī)范可以參考已有的

4、一些Java編程規(guī)范書籍和其他相關(guān)資料并結(jié)合項目的本身來制定，可供參考的書籍有Java編程風(fēng)格（英文書名為：TheElementsofJavaStyle）。編碼規(guī)范要形成文檔，而且要簡潔明了，并組織項目成員一起學(xué)習(xí)，確保所有成員正確理解所有條目。一旦編碼規(guī)范確定，就可以利用Eclipse自身提供的功能來控制代碼樣式和格式。具體做法是，點(diǎn)擊Eclipse的Windows->Preference菜單項，在打開的Preferences對話框的左側(cè)欄中找到Java節(jié)點(diǎn)下的子項CodeStyle（如圖2）,該項和它的子項允許您對Java代碼的樣式進(jìn)行控制。圖2.Eclipse代碼樣式設(shè)置窗口例如，

5、為了使用自動格式化工具，可以在Eclipse提供的默認(rèn)代碼格式配置的基礎(chǔ)上建立自定義的格式。在Formatter面板中，點(diǎn)擊New,輸入新的名字并選擇一個默認(rèn)的配置作為初始化格式，如圖3所示。圖3.創(chuàng)建新的代碼格式配置單擊OK后就可以在新打開的窗口中進(jìn)行修改定制自己需要的格式。如圖4所示。圖4.創(chuàng)建新的代碼格式配置修改完成后點(diǎn)擊Apply保存所作修改。同時可以點(diǎn)擊Export將當(dāng)前的格式定義導(dǎo)出成一個XML文件，這樣項目組的其他成員就可以很方便通過點(diǎn)擊圖3中的Import按鈕來導(dǎo)入該XML文件來使用同一個代碼格式定義。這樣每次在提交代碼到版本控制服務(wù)器前就可以通過Eclipse界面里的Sour

6、ce->Format菜單來對代碼進(jìn)行格式化，從而使整個項目的代碼具有相同的格式。同樣可以通過對CodeStyle下的其他項目進(jìn)行設(shè)置來幫助對Java代碼的樣式進(jìn)行控制。將所有這些樣式文件導(dǎo)出成XML文件后，同編碼規(guī)范一起歸檔，供所有項目成員使用。步驟二：靜態(tài)代碼分析在完成源代碼的開發(fā)以后，下面要進(jìn)行的工作就是審視和測試代碼。除了通過運(yùn)行測試代碼來檢查功能之外，還能利用一些靜態(tài)分析工具來快速、直接地提高代碼質(zhì)量。靜態(tài)代碼分析工具并不需要運(yùn)行代碼，可以直接對Java文件和Class文件進(jìn)行分析，通過一些檢查條件的設(shè)置，快速找到代碼中的錯誤和潛在缺陷?，F(xiàn)在的靜態(tài)分析工具很多，有FindBugs

7、、PMDIBMRationalTool,等等。在這里，選擇FindBugs作為靜態(tài)代碼分析工具。FindBugs可以和日常開發(fā)工具Eclipse進(jìn)行集成，在開發(fā)過程中，就可以方便的開始靜態(tài)代碼的檢查。通過檢查Class文件或者JAR文件，將字節(jié)碼和一組缺陷模式進(jìn)行對比，來發(fā)現(xiàn)可能存在的代碼問題。在Eclipse的開發(fā)環(huán)境中，用插件安裝的方式安裝了Findbugs后，在Eclipse的配置選項中就會多出來FindBugs的配置選項?？梢詫ψ约旱捻椖窟M(jìn)行配置，選擇需要的Detector檢查代碼。圖5.FindBugs的配置選項gPreferencesFindBugsFridBugsrJavaFin

8、dBugsanalysiseffortDeFault”Detectordetails區(qū)JI>CanedDetectorconfigurationReporterconfigurationFilterfilesDisableddetectors師IInotparticipateinFindEugsanalysis.'Grayedout'detectorswillrurijhowevertheywillnotreportanyresultstotheUL口ShowhiddendetectorsDetectoridPattern(s)SpeedCategory叵appendin

9、g!AnObjectOutput5tream10fastCorrectnessBadAppletConstructorBfiCfa之Correctness叵BadResdtSetAccessSQLfastCorrectriess0BadSyntaxForRegularExpressionREfastCorrectnessBadUseOFRetumValueRVFastDodgyBadlyOverriddenAdapterBOAFastCorrectness叵BodeanReturnNullNPfastBadpractice叵CallToUnsupportedM&thodDmFartDo

10、dgy7ChecklmfriutobleAnnotationJCIPFastSadpretke0CheckTypeQualifiersTQCorrectnessClaneldiomCNFastBadpractice*ComparatorIdiomSefastBadpracticeConFusedlnheritanceCIFastDodgy2giFu5ionEet*eenInheF3加ndQuIAmoderateDodgy叵CrossSiteScriptingHR5|X5SfastSecurity7DoInsideOoPtivilegedDPfastBadpractice0DontCatchll

11、legalMcnitorStaUExcep.IMSEFastBadpracticeDontUseEnumhimfastBadpracticeFindBugs檢查。設(shè)置好自己的規(guī)則后，在需要檢查的代碼文件夾上點(diǎn)擊右鍵，就可以啟動代碼可以是一個項目，也可以只是幾個文件。一export.+:可c,ibm.s1,nndBu甚工FindBugw漢口earBugMakers卜Ksfresh¥5，+petmimfAssignWorkingSets.+:Jcon-in.5i±llqcamLibm.s*1n后檢查完畢后，會出現(xiàn)FindBugs視圖，把所有檢查的結(jié)果根據(jù)錯誤分組展示。點(diǎn)擊結(jié)果里

12、面的每一個錯誤，會自動打開對應(yīng)的代碼。當(dāng)根據(jù)規(guī)則改正了所有的錯誤，或者說潛在錯誤，這些代碼也就通過了靜態(tài)代碼檢查。FindBugs的檢查結(jié)果可以是XML文件，也可以是文本文件，便于項目的集成管理和檢查保存。圖7.FindBugs檢查結(jié)果BueExplorer一片§會場王白口巴-J八IL/L/I乂UL/L!/JJ.ILUj，"/F"iFhirt«"mI,Firni-°ieT”er®s,.eT”iriileris,.,+it*efimi-|+iln.phoeni*,services,network(2)i-Ln?com.ibm.

13、sysiingt.configjngrplugiit.mmldapconfig(14)+Classdefijiesclcite()butdoesn'timplementCloneable(1)-卓creptioniwcaughtwhenExceptionisnotthrownCl)通ExceptioniscaughtwhftnExceptioni互notthrown+淡Shouldbeastaticinnerclass(3)i；金hUnreadfi«ld(3)+總Writetostatiefiftldfromiirstwn。athoil步驟三：單元測試單元測試用例設(shè)計和評審單

14、元測試是軟件開發(fā)過程中重要的質(zhì)量保證環(huán)節(jié)，在此環(huán)節(jié)中，設(shè)計和評審對于保證整個單元測試過程的完整性和有效性來說十分重要。設(shè)計階段需要具體考慮要對哪些代碼單元進(jìn)行測試，被測單元之間的關(guān)系，測試策略，以及單元測試用例設(shè)計等，并最終輸出單元測試用例設(shè)計文檔，用來指導(dǎo)具體的單元測試執(zhí)行。在用例設(shè)計中，通過對代碼單元輸入和期待輸出的定義來保證該單元的功能正確性，邊界值的測試和異常測試非常重要。同時也配合測試用例和功能塊的匹配方法來衡量用例設(shè)計的完整性。在用例設(shè)計完成之后，下一步的工作就是進(jìn)行測試用例的評審。個人的理解和經(jīng)驗始終是有限的，用例評審可以借集體之力，對用例設(shè)計進(jìn)入查漏補(bǔ)缺，進(jìn)一步保證測試用例的有

15、效性。由于單元測試屬于白盒測試范疇，它主要通過對代碼的邏輯結(jié)構(gòu)進(jìn)行分析來設(shè)計測試用例，因此，評審員的選擇最好以理解代碼邏輯結(jié)構(gòu)為前提，如果評審員來自相關(guān)模塊，還能夠有效的發(fā)現(xiàn)模塊相關(guān)性和依賴性所帶來的問題。模擬對象技術(shù)在實(shí)際項目中，開發(fā)人員自己的代碼往往需要和其他的代碼模塊或系統(tǒng)進(jìn)行交互，但在測試的過程中，這些需要被調(diào)用的真實(shí)對象常常很難被實(shí)例化，或者這些對象在某些情況下無法被用來測試，例如，真實(shí)對象的行為無法預(yù)測，真實(shí)對象的行為難以觸發(fā)，或者真實(shí)對象的運(yùn)行速度很慢。這時候，就需要使用模擬對象技術(shù)(Mock),利用一個模擬對象來模擬我們的代碼所依賴的真實(shí)對象，來幫助完成測試，提高測試覆蓋率，從

16、而提高代碼質(zhì)量。模擬對象技術(shù)利用了在面向接口的編程中，由于代碼直接對接口進(jìn)行調(diào)用，所以代碼并不知道引用的是真實(shí)對象還是模擬對象，這樣就可以順利的完成對代碼的測試。模擬技術(shù)有很多種，如jMock,EasyMock,Mockito,PowerMock等等。其中Mockito消除了對期望行為的需求，避免了這些代碼的大量初始化。圖8.Mockito示例/Youcanmockconcreteclasses,notonlyinterfacesLinkedListinockedL1st-mock(LinkedList.class)；/stubbing-beioreexecutionvheji(iwoclce

17、dList.get(0)»thenReturnC,first;/followingpuintsFrfirstFrSystem.out.printInmockedL1stget(0);/followingptrints"null"becauseget(999)wasnotstubbedSystem.out.println(mockedList.get(999)i;在模擬對象過程中，先模擬一個需要調(diào)用的List對象LinkedList,再設(shè)定這個對象的行為，當(dāng)調(diào)用get(0)的時候，返回"first"。這樣，測試代碼就可以利用這個對象來測試我們的功

18、能代碼，需要調(diào)用和返回值的時候，可以順利的得到模擬對象的返回值。也需要對模擬對象進(jìn)行錯誤情況的模擬，保證代碼對錯誤的處理的正確性。測試覆蓋率分析為了衡量單元測試的質(zhì)量和覆蓋的范圍，需要對單元測試的代碼進(jìn)行測試覆蓋分析。常用的衡量測試覆蓋率的指標(biāo)主要有語句覆蓋率、分支覆蓋率、路徑覆蓋率、條件覆蓋率和方法覆蓋率等。具體采用哪些指標(biāo)可以根據(jù)項目的實(shí)際情況來定，以避免因過高的指標(biāo)增加了代碼開發(fā)人員的工作量而影響了項目整體的進(jìn)度。EMM端一款比較流行的開源Java測試覆蓋率分析工具，支持類、方法、代碼行、基本代碼塊等多種類型的測試覆蓋率分析，支持將覆蓋率分析結(jié)果導(dǎo)出為多種格式的報告，并采用多種顏色來高亮

19、顯示不同的覆蓋率狀態(tài)。EdEmma是一款基于EMMA的Eclipse插件，方便在EclipseIDE中進(jìn)行測試覆蓋率分析。如圖9,在測試用例寫好后，可以在右鍵點(diǎn)擊測試類，選擇CoverageAs->JUnitTest.圖9.運(yùn)行測試覆蓋分析3Projed手sample四SHZ由由£-I!®ib-test:日由DebugAsProfileAsCoverageAsValidateTeamCompareWithReplaceWithRestorefromLocalHistory,.WebServicesPropertiesAft+Enter斗AddReviewIssue.E

20、團(tuán)山ms-:,®-®-;一MITeste.jaya：TestCommandExecijtoTestFileUtiLjava單元測試跑完后，Coverage視圖中會顯示所選擇的測試的覆蓋率。雙擊打開某一具體的類后，可以看到高亮顯示的覆蓋分析結(jié)果，如圖10所示。紅色代表測試沒有覆蓋到該行，黃色表示部分覆蓋，綠色的行表示該行在本次測試中被覆蓋到。圖10.查看測試覆蓋分析結(jié)果12.Coverage蕊d"JUnit里Console|FIX.k=】e%=AlPTests(200912-711:33:51)Element上CoverageCoveredInstructionsT

21、otalInstructionsAG0sample-啊,8%3557130-JSTC.44.5%28564011占comdbm.sample,ond71,2%126177三.=)田com.ibm.sample.utits-34,3%159喝3*CcMiimonUtite.java9,5%10105!ffi2)Constant.java24,g%明193國，T,FMeUtiLjava.50,0%3366w例如圖11.導(dǎo)出測試覆蓋分析結(jié)果在Coverage視圖中可以通過點(diǎn)擊鼠標(biāo)右鍵將測試覆蓋分析的結(jié)果導(dǎo)出成需要的格式,HTML圖12顯示了導(dǎo)出的report圖12.測試覆蓋分析報告為了保證單元測試的

22、有效性和質(zhì)量，可以規(guī)定一個測試覆蓋率的下限，例如所有的包和類的覆蓋率必須達(dá)到80%以上。不過值得注意的是，不要單純追求高覆蓋率，要同時注意測試用例的質(zhì)量，如果測試用例本身就寫的有錯誤，那么即使測試覆蓋率很高也沒有意義。步驟四：持續(xù)集成持續(xù)集成(ContinuousIntegration)是利用一系列的工具，方法和規(guī)則，做到快速的構(gòu)建開發(fā)代碼，自動的測試化，來提高開發(fā)代碼的效率和質(zhì)量。利用自動構(gòu)建工具，隨時都能把提交的代碼構(gòu)建出來，提供一個可以測試使用的版本，讓用戶和開發(fā)人員同時看到相同的功能，盡早的發(fā)現(xiàn)問題和錯誤，也可以盡快的得到測試人員和用戶的反饋。要做到持續(xù)集成，就要利用一系列工具，把開發(fā)

23、過程中的重復(fù)工作自動化。搭建自動的構(gòu)建服務(wù)器，自動的進(jìn)行單元測試和發(fā)布新版本，一個集成的服務(wù)器可以提供構(gòu)建過程的結(jié)果報告，自動通知開發(fā)人員構(gòu)建結(jié)果，并且保存歷史數(shù)據(jù)。舊MRationalTeamConcert(RTC)可以提供工作任務(wù)的管理，項目計劃的安排，代碼版本管理控制，自動構(gòu)建可用版本，生成構(gòu)建結(jié)果報告。這些過程構(gòu)成了項目的持續(xù)集成過程，其中，版本的自動構(gòu)建和代碼的自動單元測試是持續(xù)集成的關(guān)鍵過程，RTC在這些過程上提供了有力的支持。自動構(gòu)建RTC提供了buildengine來負(fù)責(zé)構(gòu)建build,首選，啟動buildengine,并和RTC服務(wù)器建立了連接。再創(chuàng)建項目的build定義。在

24、這個定義中，需要設(shè)定編譯哪些模塊的代碼，需要跳動哪個ANT文件來啟動編譯，和一些編譯過程中的參數(shù)的設(shè)定。當(dāng)這些都準(zhǔn)備好了，編譯對于項目而言，就變成一個簡單的事情?？梢钥吹?，通過在build定義上，點(diǎn)擊請求構(gòu)建，就可以觸發(fā)一次構(gòu)建過程。選擇需要的構(gòu)建參數(shù)，這個過程就會在后臺運(yùn)行。每一個開發(fā)人員，做了稍許的代碼改變和提交，都可以觸發(fā)新的構(gòu)建過程，來保證我們代碼的有效性。申請一個新的構(gòu)建的過程如圖13、圖14所示。圖13.申請一個新的構(gòu)建圖14.構(gòu)建申請界面ErD'ASSn.Name4Valueibuikl.destC;/phoenixJjuild/phoenixdestibuiki.lib

25、C:/phoenix_build/phcenixresourcebuild,tempC:/phoenixJjuiild/phoenixtempfetch.drC:/phoenix_build/phoerMxfi£cthreportfalseBuIdPropertieadRequestBuildRequestthatabuildbeexecutedorrthefirstavailablebuildengine.Build:CSTlLocalftpBuikJ-BuildOptions.PersonalBuildCheckthisoptiontomake出過apersonalbuild.T

26、hebuildwilrunusingawork5a匚uyouspecify,andwillrotimpactthebuilddefinitionstatus.Personalbuildalertswillonlybereceivedbyyou,notothermembersofyourteam1RepositoryworkspaceComponenthadrules：BuildPropertyDescription:<select&buildpcoperi?frtoseeitsdescripbon>Aftersubmittingtherequest;Showbuildsof

27、therequestedtypeSubmitCancel_當(dāng)構(gòu)建結(jié)束后。RTC服務(wù)器會提供構(gòu)建結(jié)果報告。開發(fā)人員可以查詢到這次構(gòu)建的詳細(xì)信息。整個開發(fā)過程中，構(gòu)建版本的過程應(yīng)該是無數(shù)次的，通過每次構(gòu)建，都可以得到當(dāng)時代碼的編譯情況，并且可以得到一個可運(yùn)行的軟件版本。在構(gòu)建定義上，RTC支持設(shè)置構(gòu)建計劃。定時自動的觸發(fā)一次構(gòu)建。圖16.構(gòu)建定義自動單元測試構(gòu)建可以自動了，重點(diǎn)提高代碼質(zhì)量的單元測試呢？如果每一天的代碼，每一個版本的代碼，都已經(jīng)通過了我們的單元測試，這樣我們就能對代碼的質(zhì)量有了基本的保證。在構(gòu)建腳本的自動調(diào)用過程中，通過ANT的腳本，可以加上JUnit,EMMAFindBugs的A

28、NT腳本調(diào)用,每一次的構(gòu)建，都可以把這些檢查工作自動的進(jìn)行一遍測試。這些測試都要生成測試結(jié)果報告，RTC不能提供這些報告的展示，就可以利用Hudson這個開源工具，集成測試報告來方便查閱。圖17.自動測試報告ProjectSampleProjectUm.A4AW4*1ff,*il3*«t1«-%Er«hM步驟五：代碼評審和重構(gòu)代碼評審(CodeReview)是Java項目開發(fā)過程中的一個重要步驟，代碼評審可以幫助發(fā)現(xiàn)靜態(tài)代碼分析過程中無法發(fā)現(xiàn)的一些問題，例如代碼的編寫是否符合編碼規(guī)范，代碼在邏輯上或者功能上是否存在錯誤，代碼在執(zhí)行效率和性能上是否有需要改進(jìn)的地方，代碼的注釋是否完整正確，代碼是否存在冗余和重復(fù)。代碼評審還可以幫助新進(jìn)入項目組的成員快速學(xué)習(xí)和了解項目，促進(jìn)經(jīng)驗分享，同時也能保證項目成員的良好溝通。代碼評審主要包括兩種形式，同級評審(PeerReview)和小組評審(GroupReview)。同級評審主要指項目成員間的互相評審，小組評審是指通過召開評審會議，項目成員一起對項目代碼進(jìn)行評審。為了提高代碼評審的有效性和效率，可以借助一些外部工具，比較常用的代碼評審工具有Jupiter和CodeStriker。Jupiter是一款開源的Eclipse插件，允許成員將評審意見