本文將介紹在敏捷開(kāi)發(fā)過(guò)程中如何通過(guò)采取一系列的步驟來(lái)保證和提高整個(gè)項目的代碼質(zhì)量，闡述了每一步可以利用的工具和最佳實(shí)踐，從而使開(kāi)發(fā)過(guò)程更加規范化，成就高質(zhì)量的代碼。

概述

Java 項目開(kāi)發(fā)過(guò)程中，由于開(kāi)發(fā)人員的經(jīng)驗、代碼風(fēng)格各不相同，以及缺乏統一的標準和管理流程，往往導致整個(gè)項目的代碼質(zhì)量較差，難于維護，需要較大的測試投入和周期等問(wèn)題。這些問(wèn)題在一個(gè)項目組初建、需求和設計均具有不完全可預期性和完備性的全新項目中將尤為突出。本文將結合敏捷開(kāi)發(fā)周期短，變化快等特點(diǎn)，介紹如何通過(guò)在開(kāi)發(fā)過(guò)程中采取一系列步驟來(lái)保證和提高整個(gè)開(kāi)發(fā)團隊的代碼質(zhì)量，并闡述了每一步可以利用的工具和最佳實(shí)踐，從而使開(kāi)發(fā)過(guò)程更加規范化，成就高質(zhì)量的代碼，減少測試的投入，并促進(jìn)整個(gè)團隊的技能提高，最終提高開(kāi)發(fā)效率和質(zhì)量。
如圖 1 所示，敏捷開(kāi)發(fā)過(guò)程經(jīng)歷需求調研，用例分析和用例分解，進(jìn)入開(kāi)發(fā)迭代階段。在每個(gè)迭代過(guò)程中，可以采用以下五個(gè)步驟來(lái)保證和提高整個(gè)項目的代碼質(zhì)量：統一編碼規范、代碼樣式；靜態(tài)代碼分析（static code review）；單元測試；持續集成；代碼評審和重構（Review & Refactor）。下文將針對每個(gè)步驟和其所使用的工具、方法進(jìn)行詳細描述。

步驟一：統一編碼規范、代碼樣式

規范統一的編碼會(huì )增加項目代碼的可讀性和可維護性，但實(shí)際情況往往是項目組內的 Java 代碼開(kāi)發(fā)人員的編碼風(fēng)格常常各不相同，這可能是由于不同的經(jīng)驗習慣或者缺乏編碼規范方面的學(xué)習造成的。這樣一來(lái)，其他項目成員或者維護人員在閱讀項目代碼時(shí)就需要花費更多的時(shí)間來(lái)理解代碼作者的意圖，所以制定并采取統一的編碼規范就顯得很重要。編碼規范主要應包含以下幾個(gè)方面：

1. 一般規則和格式規范。例如代碼縮進(jìn)、程序塊規范、每行最大代碼長(cháng)度等。
2. 命名規則。例如包名、類(lèi)名、變量、方法、接口、參數等命名規范
3. 文檔規范。例如類(lèi)文件頭聲明、類(lèi)注釋、成員變量和方法注釋等規范。
4. 編程規范。例如異常、并發(fā)、多線(xiàn)程等方面的處理方式。
5. 其他規范。例如日志格式、屬性文件格式，返回值和消息格式。

項目的編碼規范可以參考已有的一些 Java 編程規范書(shū)籍和其他相關(guān)資料并結合項目的本身來(lái)制定，可供參考的書(shū)籍有《 Java 編程風(fēng)格》（英文書(shū)名為：The Elements of Java Style）。編碼規范要形成文檔，而且要簡(jiǎn)潔明了，并組織項目成員一起學(xué)習，確保所有成員正確理解所有條目。
一旦編碼規范確定，就可以利用 Eclipse 自身提供的功能來(lái)控制代碼樣式和格式。具體做法是，點(diǎn)擊 Eclipse 的 Windows -> Preference 菜單項，在打開(kāi)的 Preferences 對話(huà)框的左側欄中找到 Java 節點(diǎn)下的子項 Code Style（如圖 2），該項和它的子項允許您對 Java 代碼的樣式進(jìn)行控制。
例如，為了使用自動(dòng)格式化工具，可以在 Eclipse 提供的默認代碼格式配置的基礎上建立自定義的格式。在 Formatter 面板中，點(diǎn)擊 New，輸入新的名字并選擇一個(gè)默認的配置作為初始化格式，如圖 3 所示。
單擊 OK 后就可以在新打開(kāi)的窗口中進(jìn)行修改定制自己需要的格式。如圖 4 所示。
修改完成后點(diǎn)擊 Apply 保存所作修改。同時(shí)可以點(diǎn)擊 Export 將當前的格式定義導出成一個(gè) XML 文件，這樣項目組的其他成員就可以很方便通過(guò)點(diǎn)擊圖 3 中的 Import 按鈕來(lái)導入該 XML 文件來(lái)使用同一個(gè)代碼格式定義。
這樣每次在提交代碼到版本控制服務(wù)器前就可以通過(guò) Eclipse 界面里的 Source->Format 菜單來(lái)對代碼進(jìn)行格式化，從而使整個(gè)項目的代碼具有相同的格式。同樣可以通過(guò)對 Code Style 下的其他項目進(jìn)行設置來(lái)幫助對 Java 代碼的樣式進(jìn)行控制。將所有這些樣式文件導出成 XML 文件后，同編碼規范一起歸檔，供所有項目成員使用。

步驟二：靜態(tài)代碼分析

在完成源代碼的開(kāi)發(fā)以后，下面要進(jìn)行的工作就是審視和測試代碼。除了通過(guò)運行測試代碼來(lái)檢查功能之外，還能利用一些靜態(tài)分析工具來(lái)快速、直接地提高代碼質(zhì)量。靜態(tài)代碼分析工具并不需要運行代碼，可以直接對 Java 文件和 Class 文件進(jìn)行分析，通過(guò)一些檢查條件的設置，快速找到代碼中的錯誤和潛在缺陷?，F在的靜態(tài)分析工具很多，有 FindBugs、PMD、IBM Rational Tool，等等。在這里，選擇 FindBugs 作為靜態(tài)代碼分析工具。FindBugs 可以和日常開(kāi)發(fā)工具 Eclipse 進(jìn)行集成，在開(kāi)發(fā)過(guò)程中，就可以方便的開(kāi)始靜態(tài)代碼的檢查。通過(guò)檢查 Class 文件或者 JAR 文件，將字節碼和一組缺陷模式進(jìn)行對比，來(lái)發(fā)現可能存在的代碼問(wèn)題。在 Eclipse 的開(kāi)發(fā)環(huán)境中，用插件安裝的方式安裝了 Findbugs 后，在 Eclipse 的配置選項中就會(huì )多出來(lái) FindBugs 的配置選項?？梢詫ψ约旱捻椖窟M(jìn)行配置，選擇需要的 Detector 檢查代碼。
設置好自己的規則后，在需要檢查的代碼文件夾上點(diǎn)擊右鍵，就可以啟動(dòng) FindBugs 檢查。代碼可以是一個(gè)項目，也可以只是幾個(gè)文件。
檢查完畢后，會(huì )出現 FindBugs 視圖，把所有檢查的結果根據錯誤分組展示。點(diǎn)擊結果里面的每一個(gè)錯誤，會(huì )自動(dòng)打開(kāi)對應的代碼。當根據規則改正了所有的錯誤，或者說(shuō)潛在錯誤，這些代碼也就通過(guò)了靜態(tài)代碼檢查。FindBugs 的檢查結果可以是 XML 文件，也可以是文本文件，便于項目的集成管理和檢查保存。

步驟三：?jiǎn)卧獪y試

單元測試用例設計和評審

單元測試是軟件開(kāi)發(fā)過(guò)程中重要的質(zhì)量保證環(huán)節，在此環(huán)節中，設計和評審對于保證整個(gè)單元測試過(guò)程的完整性和有效性來(lái)說(shuō)十分重要。設計階段需要具體考慮要對哪些代碼單元進(jìn)行測試，被測單元之間的關(guān)系，測試策略，以及單元測試用例設計等，并最終輸出《單元測試用例設計》文檔，用來(lái)指導具體的單元測試執行。在用例設計中，通過(guò)對代碼單元輸入和期待輸出的定義來(lái)保證該單元的功能正確性，邊界值的測試和異常測試非常重要。同時(shí)也配合測試用例和功能塊的匹配方法來(lái)衡量用例設計的完整性。
在用例設計完成之后，下一步的工作就是進(jìn)行測試用例的評審。個(gè)人的理解和經(jīng)驗始終是有限的，用例評審可以借集體之力，對用例設計進(jìn)入查漏補缺，進(jìn)一步保證測試用例的有效性。由于單元測試屬于白盒測試范疇，它主要通過(guò)對代碼的邏輯結構進(jìn)行分析來(lái)設計測試用例，因此，評審員的選擇最好以理解代碼邏輯結構為前提，如果評審員來(lái)自相關(guān)模塊，還能夠有效的發(fā)現模塊相關(guān)性和依賴(lài)性所帶來(lái)的問(wèn)題。

模擬對象技術(shù)

在實(shí)際項目中，開(kāi)發(fā)人員自己的代碼往往需要和其他的代碼模塊或系統進(jìn)行交互，但在測試的過(guò)程中，這些需要被調用的真實(shí)對象常常很難被實(shí)例化，或者這些對象在某些情況下無(wú)法被用來(lái)測試，例如，真實(shí)對象的行為無(wú)法預測，真實(shí)對象的行為難以觸發(fā)，或者真實(shí)對象的運行速度很慢。這時(shí)候，就需要使用模擬對象技術(shù)（Mock），利用一個(gè)模擬對象來(lái)模擬我們的代碼所依賴(lài)的真實(shí)對象，來(lái)幫助完成測試，提高測試覆蓋率，從而提高代碼質(zhì)量。模擬對象技術(shù)利用了在面向接口的編程中，由于代碼直接對接口進(jìn)行調用，所以代碼并不知道引用的是真實(shí)對象還是模擬對象，這樣就可以順利的完成對代碼的測試。
模擬技術(shù)有很多種，如 jMock，EasyMock，Mockito，PowerMock 等等。其中 Mockito 消除了對期望行為的需求，避免了這些代碼的大量初始化。
在模擬對象過(guò)程中，先模擬一個(gè)需要調用的 List 對象 LinkedList，再設定這個(gè)對象的行為，當調用 get(0) 的時(shí)候，返回”first”。這樣，測試代碼就可以利用這個(gè)對象來(lái)測試我們的功能代碼，需要調用和返回值的時(shí)候，可以順利的得到模擬對象的返回值。也需要對模擬對象進(jìn)行錯誤情況的模擬，保證代碼對錯誤的處理的正確性。

測試覆蓋率分析

為了衡量單元測試的質(zhì)量和覆蓋的范圍，需要對單元測試的代碼進(jìn)行測試覆蓋分析。常用的衡量測試覆蓋率的指標主要有語(yǔ)句覆蓋率、分支覆蓋率、路徑覆蓋率、條件覆蓋率和方法覆蓋率等。具體采用哪些指標可以根據項目的實(shí)際情況來(lái)定，以避免因過(guò)高的指標增加了代碼開(kāi)發(fā)人員的工作量而影響了項目整體的進(jìn)度。
EMMA 是一款比較流行的開(kāi)源 Java 測試覆蓋率分析工具，支持類(lèi)、方法、代碼行、基本代碼塊等多種類(lèi)型的測試覆蓋率分析，支持將覆蓋率分析結果導出為多種格式的報告，并采用多種顏色來(lái)高亮顯示不同的覆蓋率狀態(tài)。EclEmma 是一款基于 EMMA 的 Eclipse 插件，方便在 Eclipse IDE 中進(jìn)行測試覆蓋率分析。如圖 9，在測試用例寫(xiě)好后，可以在右鍵點(diǎn)擊測試類(lèi)，選擇 Coverage As -> JUnit Test.
單元測試跑完后，Coverage視圖中會(huì )顯示所選擇的測試的覆蓋率。雙擊打開(kāi)某一具體的類(lèi)后，可以看到高亮顯示的覆蓋分析結果，如圖 10 所示。紅色代表測試沒(méi)有覆蓋到該行，黃色表示部分覆蓋，綠色的行表示該行在本次測試中被覆蓋到。
在 Coverage 視圖中可以通過(guò)點(diǎn)擊鼠標右鍵將測試覆蓋分析的結果導出成需要的格式，例如 HTML。
圖 12 顯示了導出的 report。
為了保證單元測試的有效性和質(zhì)量，可以規定一個(gè)測試覆蓋率的下限，例如所有的包和類(lèi)的覆蓋率必須達到 80% 以上。不過(guò)值得注意的是，不要單純追求高覆蓋率，要同時(shí)注意測試用例的質(zhì)量，如果測試用例本身就寫(xiě)的有錯誤，那么即使測試覆蓋率很高也沒(méi)有意義。

步驟四：持續集成

持續集成（Continuous Integration）是利用一系列的工具，方法和規則，做到快速的構建開(kāi)發(fā)代碼，自動(dòng)的測試化，來(lái)提高開(kāi)發(fā)代碼的效率和質(zhì)量。利用自動(dòng)構建工具，隨時(shí)都能把提交的代碼構建出來(lái)，提供一個(gè)可以測試使用的版本，讓用戶(hù)和開(kāi)發(fā)人員同時(shí)看到相同的功能，盡早的發(fā)現問(wèn)題和錯誤，也可以盡快的得到測試人員和用戶(hù)的反饋。
要做到持續集成，就要利用一系列工具，把開(kāi)發(fā)過(guò)程中的重復工作自動(dòng)化。搭建自動(dòng)的構建服務(wù)器，自動(dòng)的進(jìn)行單元測試和發(fā)布新版本，一個(gè)集成的服務(wù)器可以提供構建過(guò)程的結果報告，自動(dòng)通知開(kāi)發(fā)人員構建結果，并且保存歷史數據。IBM Rational Team Concert (RTC) 可以提供工作任務(wù)的管理，項目計劃的安排，代碼版本管理控制，自動(dòng)構建可用版本，生成構建結果報告。這些過(guò)程構成了項目的持續集成過(guò)程，其中，版本的自動(dòng)構建和代碼的自動(dòng)單元測試是持續集成的關(guān)鍵過(guò)程，RTC 在這些過(guò)程上提供了有力的支持。

自動(dòng)構建

RTC 提供了 build engine 來(lái)負責構建 build，首選，啟動(dòng) build engine，并和 RTC 服務(wù)器建立了連接。再創(chuàng )建項目的 build 定義。在這個(gè)定義中，需要設定編譯哪些模塊的代碼，需要跳動(dòng)哪個(gè) ANT 文件來(lái)啟動(dòng)編譯，和一些編譯過(guò)程中的參數的設定。當這些都準備好了，編譯對于項目而言，就變成一個(gè)簡(jiǎn)單的事情。
可以看到，通過(guò)在 build 定義上，點(diǎn)擊請求構建，就可以觸發(fā)一次構建過(guò)程。選擇需要的構建參數，這個(gè)過(guò)程就會(huì )在后臺運行。每一個(gè)開(kāi)發(fā)人員，做了稍許的代碼改變和提交，都可以觸發(fā)新的構建過(guò)程，來(lái)保證我們代碼的有效性。申請一個(gè)新的構建的過(guò)程如圖 13、圖 14 所示。
當構建結束后。RTC 服務(wù)器會(huì )提供構建結果報告。開(kāi)發(fā)人員可以查詢(xún)到這次構建的詳細信息。
整個(gè)開(kāi)發(fā)過(guò)程中，構建版本的過(guò)程應該是無(wú)數次的，通過(guò)每次構建，都可以得到當時(shí)代碼的編譯情況，并且可以得到一個(gè)可運行的軟件版本。在構建定義上，RTC 支持設置構建計劃。定時(shí)自動(dòng)的觸發(fā)一次構建。

自動(dòng)單元測試

構建可以自動(dòng)了，重點(diǎn)提高代碼質(zhì)量的單元測試呢？如果每一天的代碼，每一個(gè)版本的代碼，都已經(jīng)通過(guò)了我們的單元測試，這樣我們就能對代碼的質(zhì)量有了基本的保證。在構建腳本的自動(dòng)調用過(guò)程中，通過(guò) ANT 的腳本，可以加上 JUnit，EMMA，FindBugs 的 ANT 腳本調用，每一次的構建，都可以把這些檢查工作自動(dòng)的進(jìn)行一遍測試。這些測試都要生成測試結果報告， RTC 不能提供這些報告的展示，就可以利用 Hudson 這個(gè)開(kāi)源工具，集成測試報告來(lái)方便查閱。

步驟五：代碼評審和重構

代碼評審（Code Review）是 Java 項目開(kāi)發(fā)過(guò)程中的一個(gè)重要步驟，代碼評審可以幫助發(fā)現靜態(tài)代碼分析過(guò)程中無(wú)法發(fā)現的一些問(wèn)題，例如代碼的編寫(xiě)是否符合編碼規范，代碼在邏輯上或者功能上是否存在錯誤，代碼在執行效率和性能上是否有需要改進(jìn)的地方，代碼的注釋是否完整正確，代碼是否存在冗余和重復。代碼評審還可以幫助新進(jìn)入項目組的成員快速學(xué)習和了解項目，促進(jìn)經(jīng)驗分享，同時(shí)也能保證項目成員的良好溝通。代碼評審主要包括兩種形式，同級評審（Peer Review）和小組評審（Group Review）。同級評審主要指項目成員間的互相評審，小組評審是指通過(guò)召開(kāi)評審會(huì )議，項目成員一起對項目代碼進(jìn)行評審。
為了提高代碼評審的有效性和效率，可以借助一些外部工具，比較常用的代碼評審工具有 Jupiter 和 Code Striker。Jupiter 是一款開(kāi)源的 Eclipse 插件，允許成員將評審意見(jiàn)定位到真實(shí)代碼的具體行，由于代碼評審的結果以 XML 文件的形式保存，所以可以把結果提交到版本管理服務(wù)器進(jìn)行共享。圖 18 顯示了使用 Jupiter 進(jìn)行代碼評審的界面。
在代碼評審任務(wù)創(chuàng )建后，Jupiter 將代碼評審分成三個(gè)階段，個(gè)人評審階段 (Individual Phase)、團隊評審階段（Team Phase）和問(wèn)題修復階段（Rework Phase）。在個(gè)人評審階段，評審成員將發(fā)現的代碼問(wèn)題或者缺陷記錄下來(lái)，每個(gè)問(wèn)題都會(huì )作為一個(gè)記錄保存在評審表格中。在團隊評審階段，團隊的全部或者部分成員會(huì )一起對個(gè)人評審階段發(fā)現的問(wèn)題進(jìn)行定性，如果問(wèn)題確實(shí)存在，就將該問(wèn)題分配給某個(gè)成員去解決，并在 Jupiter 中將該問(wèn)題設置成相應的狀態(tài)。在問(wèn)題修復階段，團隊成員會(huì )修復屬于自己的問(wèn)題，并將相應的記錄設置成已解決等正確的狀態(tài)。
Codestriker 是一款基于 Web 的常用代碼評審工具，對代碼的評審可以針對某一具體行，也可以針對整個(gè)代碼文件，評審意見(jiàn)會(huì )被保存在數據庫中。評審人員可以同時(shí)看到其他人的評論，代碼作者也可以針對某一具體的評論回復。Codestriker 支持郵件通知，還可以同版本控制服務(wù)器進(jìn)行集成，以跟蹤和顯示文件內容的改變。圖 19 顯示了 Codestriker 的界面。
在實(shí)踐中對所有代碼進(jìn)行小組評審會(huì )比較費時(shí)，所以可以根據實(shí)際情況來(lái)挑選一些核心代碼進(jìn)行小組評審，或者在項目的前期安排較多的小組評審，等項目組的成員對代碼評審的標準和要求有較好的理解，進(jìn)行代碼評審的經(jīng)驗提高后，就可以逐漸減少小組評審的次數，從而達到大部分代碼即使只進(jìn)行同級評審也能保證很好的質(zhì)量。
通過(guò)代碼評審發(fā)現的問(wèn)題要通過(guò)代碼重構及時(shí)解決掉，較小的不涉及多人代碼的重構可以由項目成員自己借助 Eclipse 的重構功能完成，不同項目成員寫(xiě)的實(shí)現相同功能的不同代碼要通過(guò)討論整合成公共的類(lèi)或者方法。比較復雜的或者比較高層次的重構工作，例如整個(gè)項目層面的代碼組織形式的改變需要由整個(gè)項目組共同討論完成。

結論

軟件開(kāi)發(fā)沒(méi)有一成不變、萬(wàn)能通用的流程和方法，希望大家能從本文得到啟發(fā)和收益，結合您的實(shí)際項目特點(diǎn)，實(shí)踐以上步驟和方法，并加以完善和改進(jìn)，共同打造高效高質(zhì)量的 Java 代碼，為您的項目成功奠定堅實(shí)的基礎。