提高代碼質(zhì)量的各個(gè)關(guān)注點(diǎn)和相關(guān)的軟件介紹本文將向你介紹提高代碼質(zhì)量的各個(gè)關(guān)注點(diǎn)，主要從靜態(tài)代碼分析，代碼覆蓋率分析，運(yùn)行時(shí)內(nèi)存分析，性能分析和優(yōu)化，線程分析、錯(cuò)誤檢測(cè)5個(gè)方面來簡(jiǎn)單的介紹一下。另外第二部分簡(jiǎn)單介紹一下一些比較常見的保證代碼質(zhì)量的軟件，主要說的是eclipse插件。如:checkstyle,findbugs,PMD,JDepend,EclEmma等。目錄TOC\o"1-5"\h\z目錄 2一、提高代碼質(zhì)量 3提高代碼質(zhì)量的巨大經(jīng)濟(jì)收益 3提高代碼質(zhì)量的幾個(gè)關(guān)注點(diǎn) 4靜態(tài)代碼分析 4代碼覆蓋率分析 4運(yùn)行時(shí)內(nèi)存分析 4性能分析和優(yōu)化 52.5. 線程分析、錯(cuò)誤檢測(cè) 6如何挑選白盒測(cè)試工具 6功能因素 6價(jià)格因素 6易用性 64. 合適的才是最好的 6二、一些常見的自動(dòng)化代碼檢查的工具 81. 靜態(tài)代碼檢查工具checkstyle,findbugs,PMD簡(jiǎn)單介紹 82. 代碼覆蓋率分析 93. 檢查包依賴的插件介紹 104. 對(duì)重復(fù)的代碼行進(jìn)行檢測(cè) 11內(nèi)存分析 11 11 11參考資料： 錯(cuò)誤！未定義書簽。一、提高代碼質(zhì)量代碼質(zhì)量是在軟件滿足了設(shè)計(jì)功能的前提下，對(duì)軟件代碼執(zhí)行的可靠性、穩(wěn)定性和高性能的一種更高的要求。如何能夠有效提高代碼質(zhì)量，又節(jié)約程序員查找和修復(fù)bug的時(shí)間，成了一個(gè)難題。白盒測(cè)試工具的引入，恰好解決了這一難題。提高代碼質(zhì)量的巨大經(jīng)濟(jì)收益從提高軟件投資回報(bào)的角度出發(fā)，企業(yè)應(yīng)在降低開發(fā)成本的同時(shí)，提高軟件的可用性，這就意味著盡量減少應(yīng)用程序中的bug和性能缺陷。而由于代碼編寫過程的人為因素，代碼中的bug是不可避免的。據(jù)統(tǒng)計(jì)，每千行軟件代碼中，就可能存在20到30個(gè)bug。在無法避免bug產(chǎn)生的情況下，如何發(fā)現(xiàn)并及時(shí)消除這些bug，就成了提高軟件投資回報(bào)的唯一可行辦法。首先，我們來看看修復(fù)一個(gè)bug所需要的成本。在軟件交付周期的不同階段，修復(fù)一個(gè)bug所需的成本差別非常之大。越是到了軟件交付的后期，修復(fù)bug越困難，成本也就越高。從圖1可以看出，在測(cè)試階段修復(fù)bug的代價(jià)是開發(fā)階段的幾倍，而一旦產(chǎn)品上線，進(jìn)入維護(hù)期后，所需的代價(jià)更是達(dá)到幾十倍。S139成就夢(mèng)想IUHM技術(shù)KTGOSTOFCORRECTINGADEFECTineachstageofsoftwaredevelopment$7.1訂釘D2S139成就夢(mèng)想IUHM技術(shù)KTGOSTOFCORRECTINGADEFECTineachstageofsoftwaredevelopment$7.1訂釘D23■iIhdI1*1〔圖1根據(jù)國(guó)際上的經(jīng)驗(yàn)，在測(cè)試階段修復(fù)一個(gè)bug的時(shí)間往往要比在代碼編寫階段要多出15到75倍。因此，越早發(fā)現(xiàn)bug，越早解決，企業(yè)所付出的代價(jià)就越小。我們建議在軟件進(jìn)入測(cè)試階段之前就解決掉大部分的bug，即交付高質(zhì)量代碼的意義所在。提高代碼質(zhì)量的幾個(gè)關(guān)注點(diǎn)代碼質(zhì)量是在程序滿足了設(shè)計(jì)功能的前提下，對(duì)軟件代碼執(zhí)行的可靠性、穩(wěn)定性和高性能的一種更高的要求。為了保證交付給測(cè)試人員的代碼能夠滿足上述質(zhì)量方面的要求，在開發(fā)階段應(yīng)該對(duì)代碼進(jìn)行如下方面的測(cè)試：2.1.靜態(tài)代碼分析為保正團(tuán)隊(duì)內(nèi)各程序員之間編寫習(xí)慣的一致性和規(guī)范性，消除容易導(dǎo)致錯(cuò)誤的語(yǔ)法隱患，通常會(huì)制定一系列的編程規(guī)范。靜態(tài)代碼分析，即要求程序員對(duì)所有代碼行進(jìn)行規(guī)范性檢查，消滅潛在隱患，提高代碼的可靠性。靜態(tài)代碼分析的好處在于能發(fā)現(xiàn)大量潛在的軟件缺陷。publicvoidignorReturnValue(){Stringstr="HelloWord";str.replace('H','h');if("helloWord".equals(str)){//并不像我們期望的那樣相等，實(shí)際上是不相等}}這是使用findbugs就可以很容易的找出這個(gè)隱藏的極深的bug。這樣，就可以避免潛在的異常錯(cuò)誤。而類似的這樣問題，IDE的語(yǔ)法檢查通常沒有辦法，只有通過手工或自動(dòng)化的代碼檢查來發(fā)現(xiàn)和解決。沒有經(jīng)過靜態(tài)分析的程序可能跑起來不錯(cuò)，而實(shí)際上可能像一塊奶酪一樣，滿身是漏洞，問題一出現(xiàn)就很嚴(yán)重而且直接面對(duì)問題的是可能是最終用戶。代碼覆蓋率分析只有經(jīng)過充分測(cè)試的代碼，質(zhì)量才是有保障的。而程序員在做單元測(cè)試時(shí)，往往很難遍歷所有的分支情況，尤其是程序?qū)﹀e(cuò)誤輸入的反應(yīng)往往被忽略。因此，對(duì)代碼的測(cè)試覆蓋率分析是保證交付高質(zhì)量代碼的關(guān)鍵。利用一些代碼覆蓋率檢查工具，不僅可以了解代碼的整體測(cè)試水平，也能夠指出未經(jīng)過測(cè)試的代碼，給程序員以方向上的指引。運(yùn)行時(shí)內(nèi)存分析內(nèi)存往往是導(dǎo)致嚴(yán)重性能故障的根本原因，而一些不良的編程習(xí)慣經(jīng)常會(huì)導(dǎo)致運(yùn)行時(shí)的內(nèi)存泄露。這類問題幾乎無法通過單元測(cè)試或功能驗(yàn)證來發(fā)現(xiàn)，而又經(jīng)常被程序員忽視，直到軟件投入生產(chǎn)后才逐漸暴露出來，這時(shí)再查找和修復(fù)內(nèi)存問題就非常困難了。因此，應(yīng)盡量在代碼交付之前消滅內(nèi)存問題。運(yùn)行時(shí)內(nèi)存分析，即在代碼調(diào)試階段，對(duì)所有對(duì)象的內(nèi)存占用狀態(tài)的運(yùn)行時(shí)分析，查找內(nèi)存泄露的隱患。運(yùn)行時(shí)內(nèi)存分析的第一步就是內(nèi)存使用的監(jiān)控，以便了解在運(yùn)行期間，程序?qū)?nèi)存的使用和釋放情況，查找程序?qū)?nèi)存的不當(dāng)使用。

如下圖所示，在A點(diǎn)位置，程序穩(wěn)定運(yùn)行，對(duì)內(nèi)存的使用也基本穩(wěn)定。曲點(diǎn)，我們打開程序的某個(gè)窗口時(shí)，程序使用了更多的內(nèi)存來儲(chǔ)存新的對(duì)象。當(dāng)窗口關(guān)閉時(shí)，這些對(duì)象被釋放，內(nèi)存也應(yīng)隨之釋放。而從圖上B點(diǎn)之后的內(nèi)存使用情況來看，這些內(nèi)存并沒有被釋放。因而，可能存在著內(nèi)存泄露。在C點(diǎn)和D點(diǎn)再次打開前面的窗口，內(nèi)存還是不斷增加而沒有回收?？梢詳喽?，該窗口對(duì)應(yīng)的代碼存在內(nèi)存泄露的問題。IISystemMemory PrcfiledMemoryIISystemMemory PrcfiledMemory雖然無論是Java還是.Net,都提供了自動(dòng)的內(nèi)存回收機(jī)制，但內(nèi)存泄露仍是引起應(yīng)用系統(tǒng)性能劣化的一個(gè)主要原因。Java采用了垃圾回收機(jī)制，任何不可達(dá)對(duì)象都可以由垃圾收集線程回收。因此通常說的Java內(nèi)存泄漏其實(shí)是指無意識(shí)的、非故意的對(duì)象引用，或者無意識(shí)的對(duì)象保持。無意識(shí)的對(duì)象引用是指代碼的開發(fā)人員本來已經(jīng)對(duì)對(duì)象使用完畢，卻因?yàn)榫幋a的錯(cuò)誤而意外地保存了對(duì)該對(duì)象的引用(這個(gè)引用的存在并不是編碼人員的主觀意愿)，從而使得該對(duì)象一直無法被垃圾回收器回收掉，這種本來以為可以釋放掉的卻最終未能被釋放的空間可以認(rèn)為是被“泄漏”了。另外舉個(gè)錯(cuò)誤的內(nèi)存泄露的問題代碼。//對(duì)stock進(jìn)行的一個(gè)pop操作publicObjectpop(){Objecte=elements[--size];returne;}正是pop操作中只返回了e,而沒有將elements中無用的對(duì)象賦值為null,于是每次pop操作就產(chǎn)生了內(nèi)存泄露的問題。2.4.性能分析和優(yōu)化代碼的執(zhí)行效率，直接影響著應(yīng)用程序的可用性和可靠性。因此，軟件的性能問題應(yīng)該在開發(fā)階段就充分加以考慮，提高代碼的執(zhí)行效率，而不是把性能問題全部留到壓力測(cè)試階段去解決。性能分析和優(yōu)化，即要求在代碼提交之間，對(duì)每一個(gè)功能實(shí)現(xiàn)的響應(yīng)時(shí)間以及每個(gè)方法的效率進(jìn)行分析，并對(duì)運(yùn)行效率較低的代碼進(jìn)行優(yōu)化，從而提高代碼的整體性能，保證交付高質(zhì)量的代碼。程序員總是被要求優(yōu)化某段代碼，縮短執(zhí)行時(shí)間，但這并不是一件容易的事情。困難就在于，代碼執(zhí)行是一個(gè)非常復(fù)雜的過程，包含了太多的分支和無數(shù)的方法、代碼行，往往讓程序員無從著手。這就需要借助一些動(dòng)態(tài)的代碼分析工具，幫助程序員了解每個(gè)方法及代碼行的執(zhí)行效率，從而有針對(duì)性地對(duì)那些執(zhí)行時(shí)間最長(zhǎng)的方法或代碼行進(jìn)行性能改進(jìn)。動(dòng)態(tài)代碼分析工具應(yīng)能夠提供諸如運(yùn)行期間調(diào)用了哪些文件、方法、代碼行，每個(gè)文件、方法和代碼行的執(zhí)行時(shí)間、對(duì)總體運(yùn)行時(shí)間的影響程度等等。有了這些信息，程序員就能夠找出影響執(zhí)行時(shí)間的關(guān)鍵路徑，有效改進(jìn)代碼性能。2.5.線程分析、錯(cuò)誤檢測(cè)在Java編程中，線程是一個(gè)非常好的技術(shù)，它可以讓程序更加靈活更加強(qiáng)大。但是，線程技術(shù)的誤用同樣也會(huì)帶來非常嚴(yán)重的問題，而且線程問題是最難定位和修復(fù)的問題之一。在代碼交付之前，程序員應(yīng)充分分析和判斷代碼執(zhí)行過程中是否存在線程死鎖以及代碼在什么位置使用了鎖和同步機(jī)制等等，避免將線程問題拖延到系統(tǒng)測(cè)試階段。與性能分析類似，線程的死鎖很難通過手工的方式去判斷，必須日借助動(dòng)態(tài)的代碼分析工具，了解線程間的調(diào)用次序、同步機(jī)制以及判斷死鎖。告別“刀耕火種”的手工時(shí)代隨著軟件應(yīng)用環(huán)境的日趨復(fù)雜，對(duì)軟件質(zhì)量的要求越來越高。而隨著敏捷式開發(fā)等新的開發(fā)方式的出現(xiàn)，開發(fā)的周期越來越短。顯然，再依靠過去人工的方式逐行Review代碼、統(tǒng)計(jì)測(cè)試覆蓋率、查找bug等，實(shí)在是力不從心。幸運(yùn)的是，越來越強(qiáng)大的白盒測(cè)試工具的出現(xiàn)，彌補(bǔ)了這一點(diǎn)人力的不足。如何挑選白盒測(cè)試工具如何挑選白盒測(cè)試工具工欲善其事，必先利其器。挑選一款合適的白盒測(cè)試工具，能夠有效的提高代碼質(zhì)量和節(jié)約開發(fā)人員的時(shí)間。下面筆者就結(jié)合自己所知，嘗試解讀挑選白盒測(cè)試工具的幾個(gè)考慮因素。功能因素首先，應(yīng)考慮工具支持的語(yǔ)言和平臺(tái)。目前主流測(cè)試工具支持的開發(fā)語(yǔ)言包括Net和Java，針對(duì)不同的語(yǔ)言，實(shí)現(xiàn)方式一般有較大差異。其次，選擇適合的功能。并非功能越豐富越好，而是應(yīng)該選擇適用于自己應(yīng)用場(chǎng)景和測(cè)試要求的工具。若對(duì)軟件質(zhì)量的要求較為嚴(yán)格，如軍工、航天軟件，則需要更多、更強(qiáng)的的白盒測(cè)試手段支持。若一般的自用或簡(jiǎn)單商用軟件，則可以考慮某些功能簡(jiǎn)單又有較強(qiáng)針對(duì)性的工具，甚至是開源工具。再次，要考慮工具的集成能力。那些提供與開發(fā)環(huán)境向集成的白盒測(cè)試工具，能夠避免程序員在開發(fā)和調(diào)試階段在多個(gè)窗口之間頻繁切換，節(jié)約寶貴的時(shí)間。價(jià)格因素任何一個(gè)軟件的開發(fā)，都必須考慮成本的壓力。對(duì)功能的要求越高，相應(yīng)的工具軟件肯定越昂貴，例如Rational就不是每個(gè)企業(yè)都負(fù)擔(dān)得起的。易用性在選擇白盒工具時(shí)，還要考慮到使用人員的技術(shù)素養(yǎng)以及工具的易用性。某些工具雖然功能強(qiáng)大，但易用性不高，需要較長(zhǎng)時(shí)間摸索學(xué)習(xí)。一般，提供網(wǎng)上下載試用的工具會(huì)有比較好的易用性。合適的才是最好的正如您從本文中看到的那樣，將針對(duì)五個(gè)提高代碼測(cè)量關(guān)注點(diǎn)，即靜態(tài)分析，代碼覆蓋率分析、運(yùn)行時(shí)內(nèi)存分析、性能分析和優(yōu)化和線程分析、錯(cuò)誤檢測(cè)的測(cè)試工具用于改進(jìn)代碼質(zhì)量十分重要。但適合您的才是好的。請(qǐng)記住還有其他許多可用的Eclipse插件能夠幫助您在開發(fā)周期的早期改進(jìn)代碼質(zhì)量。不管您想要的工具或偏愛的方法是什么，重要的是行動(dòng)起來去積極改進(jìn)代碼質(zhì)量并讓手工代碼檢驗(yàn)的過程變得更加有效。我估計(jì)您使用這些插件一段時(shí)間后，就再也離不開它們了。、一些常見的自動(dòng)化代碼檢查的工具1.靜態(tài)代碼檢查工具checkstyle,findbugs,PMD簡(jiǎn)單介紹packagecoin.rb.owk.emnia;2Checkstyle運(yùn)行效果StartOWK.i?諾UWKBUGLrOWKPOSITIONHelleWorld,java塚StartOWK.i?諾UWKBUGLrOWKPOSITIONHelleWorld,java塚Hellni*iijrld.jHelloWorldTest.jHellofforId.ast@SuJTKSystemLibr：iry[IBMJDK]?Refere:由￡5?report+”斜testfindbu^+I-E?testPMDpulilicstaticvoidmethod() {intrand=(int)(Math?z■白衛(wèi)已咖()藍(lán)：LOCI);System?out■匸ii7intJ.n("Hello,world!0rr);System?口口七.pisin匸丄n(,rH已丄丄worId!lrr);PMD運(yùn)行效果Findbugs運(yùn)行效果

三者的比較工具目的主要檢查內(nèi)容FindBugs基于BugPatterns概念，查找javabytecode中的潛在bug。主要檢查bytecode中的bugpatterns,也允許用戶自定義特定的bugpatternso

官網(wǎng)：/PMD檢查java源文件中的潛在問題。官網(wǎng)./主要包括：2空try/catch/finally/switch語(yǔ)句塊2未使用的局部變量、參數(shù)和private方法2空if/while語(yǔ)句2過于復(fù)雜的表達(dá)式，如不必要的if語(yǔ)句等2復(fù)雜類CheckStyle檢查java源文件是否與代碼規(guī)范相符官網(wǎng)：/主要包括2Javadoc注釋2命名規(guī)范2Headers2Imports2Size沖突和度量，如過長(zhǎng)的方法2Whitespace2Modifiers2Blocks2CodingProblems2ClassDesign2重復(fù)代碼2MiscellaneousChecks2OptionalChecks代碼覆蓋率分析EclEmma它能夠?qū)τ蒍ava語(yǔ)言編寫的程序進(jìn)行覆蓋測(cè)試，從而對(duì)程序運(yùn)行的結(jié)果生成詳盡的覆蓋測(cè)試報(bào)告。EclEmma是一個(gè)基于EMMA的Java代碼覆蓋工具。它的目的是讓你可以在Eclipse工作平臺(tái)中使用強(qiáng)大的Java代碼覆蓋工具EMMA。EclEmma是非侵入式的不需要修改你的項(xiàng)目或執(zhí)行其它任何安裝，它能夠在工作平臺(tái)中啟動(dòng)像運(yùn)行JUnit測(cè)試一樣直接對(duì)代碼覆蓋進(jìn)行分析。覆蓋結(jié)果將立即被匯總并在Java源代碼編輯器中高亮顯示。

EclEMMA使用效果圖官網(wǎng)：/檢查包依賴的插件介紹JDepend—個(gè)開放源代碼的可以用來評(píng)價(jià)Java程序質(zhì)量的優(yōu)秀工具，它遍歷Javaclass的文件目錄，以Java包（package）為單位，為每一個(gè)包/類自動(dòng)生成包的依賴程度，穩(wěn)定性，可靠度等的評(píng)價(jià)報(bào)告，根據(jù)這些報(bào)告，我們可以得到包或類之間的依賴關(guān)系，并分析出包的穩(wěn)定程度，抽象程度，是否存在循環(huán)依耐關(guān)系等。com.-dj^sibomomcmbchinaes2k:laF%rb.dw.common,xml.mei'gei"rb.dw.common,xml.rb.dw.common,xml.rb.owkrb.owk.authority,rb.owk.authority,rb.owk.authority,rb.owk.authority,rb.owk.authority,rb.owk.authority,rb.owk.authority,rb.owk.authority,rb.owk.authority,rb.owk.authority,rb.owk.authority.rb.owk.authority.rb.owk.authority,rb.owk.authority,rb.owk.authority,rb.owk.authority,rb.owk.authority,rb.owk.authority,rb.owk.authority,rb.owk.authority,rb.owk.authority,rb.owk.authority,rb.owk.authority,rb.owk.authority,rb.owk.authority,rb.owk.authority.merger,exceptionmerger,rulecachecache,utilcascas.as400cas.as400.utilcas.cmbcas.exceptioncas.filtercas.listenerc&e.servletcas.supportcas.support,conditioncom.-dj^sibomomcmbchinaes2k:laF%rb.dw.common,xml.mei'gei"rb.dw.common,xml.rb.dw.common,xml.rb.owkrb.owk.authority,rb.owk.authority,rb.owk.authority,rb.owk.authority,rb.owk.authority,rb.owk.authority,rb.owk.authority,rb.owk.authority,rb.owk.authority,rb.owk.authority,rb.owk.authority.rb.owk.authority.rb.owk.authority,rb.owk.authority,rb.owk.authority,rb.owk.authority,rb.owk.authority,rb.owk.authority,rb.owk.authority,rb.owk.authority,rb.owk.authority,rb.owk.authority,rb.owk.authority,rb.owk.authority,rb.owk.authority,rb.owk.authority.merger,exceptionmerger,rulecachecache,utilcascas.as400cas.as400.utilcas.cmbcas.exceptioncas.filtercas.listenerc&e.servletcas.supportcas.support,conditioncas.taglibcas.userTypecas.yalecommondaodao.hibernatedao.jdbcdeploydeploy.importOrg.daodeploy.importOrg.domain,deploy.importOrg.hibernatedeploy.importOrg.jobdeploy.importOrg.servicedeploy.syncIDFackageCC(co...AC(ab...Ca(a￡f.)Cefeff.)AIDCycle!申com.rb.dw.common,xml.merger422100.330.830.16電gDependencies必、=BSelectedobject(,s)FackageCC(co...AC(ab…Ca(a￡f.)Ce(eff.)AIDCycle!申com.rb.dw.common,xml.merger422100.330.830.16申com.rb.dw.common,xml.merger,rule522T0.28O.TT0.06PackageswithcycleDependsupon-effei'entde