敏捷開發中高質量 Java 代碼開發實踐

Java 項目開發過程當中，因爲開發人員的經驗、代碼風格各不相同，以及缺少統一的標準和管理流程，每每致使整個項目的代碼質量較差，難於維護，須要較大的測試投入 和週期等問題。
這些問題在一個項目組初建、需求和設計均具備不徹底可預期性和完備性的全新項目中將尤其突出。本文將結合敏捷開發週期短，變化快等特色，介 紹如何經過在開發過程當中採起一系列步驟來保證和提升整個開發團隊的代碼質量，並闡述了每一步能夠利用的工具和最佳實踐，從而使開發過程更加規範化，成就高 質量的代碼，減小測試的投入，並促進整個團隊的技能提升，最終提升開發效率和質量。

如圖 所示，敏捷開發過程經歷需求調研，用例分析和用例分解，進入開發迭代階段。
在每一個迭代過程當中，能夠採用如下五個步驟來保證和提升整個項目的代碼質量：
統一 編碼規範、代碼樣式；
靜態代碼分析（static code review）；
單元測試；
持續集成；
代碼評審和重構（Review & Refactor）。

下文將針對每一個步驟和其所使用的工具、方法進行詳細描述。

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

規範統一的編碼會增長項目代碼的可讀性和可維護性，但實際狀況每每是項目組內的 Java 代碼開發人員的編碼風格經常各不相同，這多是因爲不一樣的經驗習慣或者缺少編碼規範方面的學習形成的。這樣一來，其餘項目成員或者維護人員在閱讀項目代碼 時就須要花費更多的時間來理解代碼做者的意圖，因此制定並採起統一的編碼規範就顯得很重要。編碼規範主要應包含如下幾個方面：

通常規則和格式規範。例如代碼縮進、程序塊規範、每行最大代碼長度等。
命名規則。例如包名、類名、變量、方法、接口、參數等命名規範
文檔規範。例如類文件頭聲明、類註釋、成員變量和方法註釋等規範。
編程規範。例如異常、併發、多線程等方面的處理方式。
其餘規範。例如日誌格式、屬性文件格式，返回值和消息格式。
項目的編碼規範能夠參考已有的一些 Java 編程規範書籍和其餘相關資料並結合項目的自己來制定，可供參考的書籍有《 Java 編程風格》（英文書名爲：The Elements of Java Style）。編碼規範要造成文檔，並且要簡潔明瞭，並組織項目成員一塊兒學習，確保全部成員正確理解全部條目。

一旦編碼規範肯定，就能夠利用 Eclipse 自身提供的功能來控制代碼樣式和格式。具體作法是，點擊 Eclipse 的 Windows -> Preference 菜單項，在打開的 Preferences 對話框的左側欄中找到 Java 節點下的子項 Code Style（如圖 2），該項和它的子項容許您對 Java 代碼的樣式進行控制。

例如，爲了使用自動格式化工具，能夠在 Eclipse 提供的默認代碼格式配置的基礎上創建自定義的格式。在 Formatter 面板中，點擊 New，輸入新的名字並選擇一個默認的配置做爲初始化格式，如圖 3 所示。

單擊 OK 後就能夠在新打開的窗口中進行修改定製本身須要的格式。如圖 4 所示。

修改完成後點擊 Apply 保存所做修改。同時能夠點擊 Export 將當前的格式定義導出成一個 XML 文件，這樣項目組的其餘成員就能夠很方便經過點擊圖 3 中的 Import 按鈕來導入該 XML 文件來使用同一個代碼格式定義。

這樣每次在提交代碼到版本控制服務器前就能夠經過 Eclipse 界面裏的 Source->Format 菜單來對代碼進行格式化，從而使整個項目的代碼具備相同的格式。一樣能夠經過對 Code Style 下的其餘項目進行設置來幫助對 Java 代碼的樣式進行控制。將全部這些樣式文件導出成 XML 文件後，同編碼規範一塊兒歸檔，供全部項目成員使用。

步驟二：靜態代碼分析

在完成源代碼的開發之後，下面要進行的工做就是審視和測試代碼。除了經過運行測試代碼來檢查功能以外，還能利用一些靜態分析工具來快速、直接 地提升代碼質量。
靜態代碼分析工具並不須要運行代碼，能夠直接對 Java 文件和 Class 文件進行分析，經過一些檢查條件的設置，快速找到代碼中的錯誤和潛在缺陷。
如今的靜態分析工具不少，有 FindBugs、PMD、IBM Rational Tool，等等。
在這裏介紹PMD，具體看以前寫的文章；

步驟三：單元測試

單元測試用例設計和評審

單元測試是軟件開發過程當中重要的質量保證環節，在此環節中，設計和評審對於保證整個單元測試過程的完整性和有效性來講十分重要。設計階段須要 具體考慮要對哪些代碼單元進行測試，被測單元之間的關係，測試策略，以及單元測試用例設計等，並最終輸出《單元測試用例設計》文檔，用來指導具體的單元測 試執行。在用例設計中，經過對代碼單元輸入和期待輸出的定義來保證該單元的功能正確性，邊界值的測試和異常測試很是重要。同時也配合測試用例和功能塊的匹 配方法來衡量用例設計的完整性。

在用例設計完成以後，下一步的工做就是進行測試用例的評審。我的的理解和經驗始終是有限的，用例評審能夠借集體之力，對用例設計進入查漏補 缺，進一步保證測試用例的有效性。因爲單元測試屬於白盒測試範疇，它主要經過對代碼的邏輯結構進行分析來設計測試用例，所以，評審員的選擇最好以理解代碼 邏輯結構爲前提，若是評審員來自相關模塊，還可以有效的發現模塊相關性和依賴性所帶來的問題。

模擬對象技術

在實際項目中，開發人員本身的代碼每每須要和其餘的代碼模塊或系統進行交互，但在測試的過程當中，這些須要被調用的真實對象經常很難被實例化， 或者這些對象在某些狀況下沒法被用來測試，例如，真實對象的行爲沒法預測，真實對象的行爲難以觸發，或者真實對象的運行速度很慢。這時候，就須要使用模擬 對象技術（Mock），利用一個模擬對象來模擬咱們的代碼所依賴的真實對象，來幫助完成測試，提升測試覆蓋率，從而提升代碼質量。模擬對象技術利用了在面 向接口的編程中，因爲代碼直接對接口進行調用，因此代碼並不知道引用的是真實對象仍是模擬對象，這樣就能夠順利的完成對代碼的測試。

模擬技術有不少種，如 jMock，EasyMock，Mockito，PowerMock 等等。其中 Mockito 消除了對指望行爲的需求，避免了這些代碼的大量初始化。

在模擬對象過程當中，先模擬一個須要調用的 List 對象 LinkedList，再設定這個對象的行爲，當調用 get(0) 的時候，返回」first」。這樣，測試代碼就能夠利用這個對象來測試咱們的功能代碼，須要調用和返回值的時候，能夠順利的獲得模擬對象的返回值。也須要 對模擬對象進行錯誤狀況的模擬，保證代碼對錯誤的處理的正確性。

測試覆蓋率分析

爲了衡量單元測試的質量和覆蓋的範圍，須要對單元測試的代碼進行測試覆蓋分析。經常使用的衡量測試覆蓋率的指標主要有語句覆蓋率、分支覆蓋率、路 徑覆蓋率、條件覆蓋率和方法覆蓋率等。具體採用哪些指標能夠根據項目的實際狀況來定，以免因太高的指標增長了代碼開發人員的工做量而影響了項目總體的進 度。

EMMA 是一款比較流行的開源 Java 測試覆蓋率分析工具，支持類、方法、代碼行、基本代碼塊等多種類型的測試覆蓋率分析，支持將覆蓋率分析結果導出爲多種格式的報告，並採用多種顏色來高亮顯 示不一樣的覆蓋率狀態。EclEmma 是一款基於 EMMA 的 Eclipse 插件，方便在 Eclipse IDE 中進行測試覆蓋率分析。

爲了保證單元測試的有效性和質量，能夠規定一個測試覆蓋率的下限，例如全部的包和類的覆蓋率必須達到 80% 以上。不過值得注意的是，不要單純追求高覆蓋率，要同時注意測試用例的質量，若是測試用例自己就寫的有錯誤，那麼即便測試覆蓋率很高也沒有意義。

步驟四：持續集成

持續集成（Continuous Integration）是利用一系列的工具，方法和規則，作到快速的構建開發代碼，自動的測試化，來提升開發代碼的效率和質量。利用自動構建工具，隨時 都能把提交的代碼構建出來，提供一個能夠測試使用的版本，讓用戶和開發人員同時看到相同的功能，儘早的發現問題和錯誤，也能夠儘快的獲得測試人員和用戶的 反饋。

要作到持續集成，就要利用一系列工具，把開發過程當中的重複工做自動化。搭建自動的構建服務器，自動的進行單元測試和發佈新版本，一個集成的服 務器能夠提供構建過程的結果報告，自動通知開發人員構建結果，而且保存歷史數據。IBM Rational Team Concert (RTC) 能夠提供工做任務的管理，項目計劃的安排，代碼版本管理控制，自動構建可用版本，生成構建結果報告。這些過程構成了項目的持續集成過程，其中，版本的自動 構建和代碼的自動單元測試是持續集成的關鍵過程，RTC 在這些過程上提供了有力的支持。

自動構建

RTC 提供了 build engine 來負責構建 build，首選，啓動 build engine，並和 RTC 服務器創建了鏈接。再建立項目的 build 定義。在這個定義中，須要設定編譯哪些模塊的代碼，須要跳動哪一個 ANT 文件來啓動編譯，和一些編譯過程當中的參數的設定。當這些都準備好了，編譯對於項目而言，就變成一個簡單的事情。

步驟五：代碼評審和重構

代碼評審（Code Review）是 Java 項目開發過程當中的一個重要步驟，代碼評審能夠幫助發現靜態代碼分析過程當中沒法發現的一些問題，例如代碼的編寫是否符合編碼規範，代碼在邏輯上或者功能上是 否存在錯誤，代碼在執行效率和性能上是否有須要改進的地方，代碼的註釋是否完整正確，代碼是否存在冗餘和重複。代碼評審還能夠幫助新進入項目組的成員快速 學習和了解項目，促進經驗分享，同時也能保證項目成員的良好溝通。代碼評審主要包括兩種形式，同級評審（Peer Review）和小組評審（Group Review）。同級評審主要指項目成員間的互相評審，小組評審是指經過召開評審會議，項目成員一塊兒對項目代碼進行評審。

爲了提升代碼評審的有效性和效率，能夠藉助一些外部工具，比較經常使用的代碼評審工具備 Jupiter 和 Code Striker。Jupiter 是一款開源的 Eclipse 插件，容許成員將評審意見定位到真實代碼的具體行，因爲代碼評審的結果以 XML 文件的形式保存，因此能夠把結果提交到版本管理服務器進行共享。

在代碼評審任務建立後，Jupiter 將代碼評審分紅三個階段，我的評審階段 (Individual Phase)、團隊評審階段（Team Phase）和問題修復階段（Rework Phase）。在我的評審階段，評審成員將發現的代碼問題或者缺陷記錄下來，每一個問題都會做爲一個記錄保存在評審表格中。在團隊評審階段，團隊的所有或者 部分紅員會一塊兒對我的評審階段發現的問題進行定性，若是問題確實存在，就將該問題分配給某個成員去解決，並在 Jupiter 中將該問題設置成相應的狀態。在問題修復階段，團隊成員會修復屬於本身的問題，並將相應的記錄設置成已解決等正確的狀態。

Codestriker 是一款基於 Web 的經常使用代碼評審工具，對代碼的評審能夠針對某一具體行，也能夠針對整個代碼文件，評審意見會被保存在數據庫中。評審人員能夠同時看到其餘人的評論，代碼做 者也能夠針對某一具體的評論回覆。Codestriker 支持郵件通知，還能夠同版本控制服務器進行集成，以跟蹤和顯示文件內容的改變。

在實踐中對全部代碼進行小組評審會比較費時，因此能夠根據實際狀況來挑選一些核心代碼進行小組評審，或者在項目的前期安排較多的小組評審，等 項目組的成員對代碼評審的標準和要求有較好的理解，進行代碼評審的經驗提升後，就能夠逐漸減小小組評審的次數，從而達到大部分代碼即便只進行同級評審也能 保證很好的質量。

經過代碼評審發現的問題要經過代碼重構及時解決掉，較小的不涉及多人代碼的重構能夠由項目成員本身藉助 Eclipse 的重構功能完成，不一樣項目成員寫的實現相同功能的不一樣代碼要經過討論整合成公共的類或者方法。比較複雜的或者比較高層次的重構工做，例如整個項目層面的代 碼組織形式的改變須要由整個項目組共同討論完成。

結論

軟件開發沒有一成不變、萬能通用的流程和方法，但願你們能從本文獲得啓發和收益，結合您的實際項目特色，實踐以上步驟和方法，並加以完善和改 進，共同打造高效高質量的 Java 代碼，爲您的項目成功奠基堅實的基礎。