確保提高你的J2EE項目的質量

2019-11-18 12:23:38

字體：大中小

來源：轉載

供稿：網友

　　概述
　　
　　許多人還在錯誤的認為基于java/ J2EE技術的系統仍然在代碼維護的問題上糾纏，bug的數量，或者功能的欠缺，或者性能的低下。幸運的是，這些問題已經很少與Java/J2EE技術本身相關聯了，與它們真正相關的是缺乏一個關注系統質量的過程。為了確保由一個大型的團隊或者跨越多團隊開發的，一個大規模的Java/J2EE項目的成功，團隊領導者必須：
　　
　　·使用能夠測量質量的工具
　　·從這些工具中定義一組質量關卡和一些人為因素
　　·分清對提交、監控的責任界限, 加強實施.
　　
　　這篇文章解釋了怎樣將這三個策略融入到你的開發戰略中，這樣才能確保你的團隊持續的開發高質量的項目。
　　
　　工具的重要性
　　
　　你聽說過一個建筑公司試圖建造一所房屋，而沒有一把高性能的電鋸，電鉆或者甚至連最基本的象錘子這樣的工具都沒有？的確，一所房屋也可以沒有今天的先進設備而建起來，但是，建筑將會花更長的時間，并且絕對達不到（使用先進工具）相同的水平。你可以用你的手建起一個小茅屋，但是假如你使用了正確的工具，你就可以建起一座大廈。
　　
　　今天的開發者與那些試圖建一所房屋的人幾乎一樣。對開發者來說工具是最基本的要素，不管是對于提高生產力還是加強質量。開發者使用的工具必須可以讓他們在最短的時間內生產出最高質量的代碼,這意昧著今天的IDE不再只是用來編寫，調試和編譯代碼的簡單工具。對應的，一個IDE必須幫助開發者識別出他們是否遵循合適的編碼規范和已知的設計模式，假如他們遵循像Web services這樣的工業標準，假如他們的代碼追隨它的約定，假如它完成每一個需求。別外，假如開發者沒有進行持續構建和自動測試的環境，那么一個IDE的能力對加強系統的質量來說就變得更重要了。
　　
　　進入Eclipse IDE看一下，它提供了內置的功能，當使用插件時，可以同時提高代碼和系統的質量。Eclipse是一個開放的，可擴展的IDE，無所不為并不專為什么而設計。Eclipse的Java開發環境是開源的，免費的和完全可訂制的。Eclipse通過開源的或商業的訂制插件來促進新功能的增加。通過使用Eclipse,非凡是圖1中顯示的一組要害的插件，那么對開發者和團隊來說，就有可能對基于J2EE或Java的項目質量進行衡量。
　　　確保提高你的J2EE項目的質量

　　圖1.Eclipse的插件矩陣圖
　　
　　假如你不能衡量和監控它，控制一個系統的質量是不可能的。理解系統中答應測量的的要害領域非常重要。它們包括系統的可維護性，可靠性和性能。上述明顯沒有全部包括全部領域，但是這三項作為確保系統質量的基石是非常合適的。
　　
　　可維護性包括了代碼理解或修改的復雜程度，不管它是一個bug修復或是一次升級。良好注釋的代碼遵守眾所周知的編碼標準和工業設計標準，它們比那些幾乎沒有注釋的，不遵守開發規范的代碼更輕易維護。高可維護的代碼可以更快地引入更改，這樣也就充許業務對新的或變化的需求有更快的響應，最后降低新特性的增加或維護造成的成本。
　　
　　可靠性表達了一個方法是否遵守它自己的約定，并能夠被成功地執行。單元測試可以用來演習一個方法的約定，從而確定代碼段的可靠性。單元測試的質量，反過來，也被代碼覆蓋分析所驗證。許多手段可以用來進行測量代碼覆蓋，包括，但不僅僅是，表達，判定，條件和調用分析。普遍討論的一個議題是用來確定一個方法的可靠性的覆蓋測試的類型和數量。出于這篇文章的目的，簡單地說可靠性會隨著代碼覆蓋測試的提高而提高。
　　
　　系統內方法的可靠性是絕對重要的，因為，擴展來說，它就代表了系統的可靠性。其它問題，如性能或可擴展性，會慢慢出現，它們在擴展單元測試和覆蓋分析時可以沒有。這樣，單元測試和覆蓋分析毫元疑問地是保證系統穩定性全部的和最終的解決方案。但是，持續穩定地執行方法的能力代表了系統穩定的好的測量棒。
　　
　　性能是典型的依靠每個單元所耗時間進行測量的。從一個系統能夠處理多少個請求，到網絡呑吐量，到某個系統調用的響應時間，全部都是依靠單元時間作為測量的標準。更為重要的是要知道，擴展開來說，是系統如何運作的。
　　
　　為了達到這樣的理解，你可能需要測量所有主要的服務方法、或者通過高使用頻率，長調用堆棧，或者那些代表了核心構造中最普遍的交易通路來體現的問題域。第一步為性能提供了不一樣的舒適度。對大型系統來說，性能應該在開發過程中被持續的維護和監控，以盡早地確定障礙并且避開生產環境下不可預知的錯誤。
　　
　　現在，讓我們來看一下Eclipse和它的插件是如何幫助開發團隊來測量任何基于Java或者J2EE系統的維護性、可靠性、和性能的。
　　
　　代碼生成：可維護性
　　
　　代碼生成是確保一致性和可重復代碼質量的最佳方法之一，它不同于基于類型的方式。XDoclet是目前生成Java源代碼的工業標準。XDoclet是一個開源的，免費的庫，它解析代碼，尋找指定的Javadoc標記（元數據），然后用它來生成其它的Java源程序。
　　
　　XDoclet包含了一組Javadoc標記，它們可以用來生成大多數的的可重復代碼，這些代碼在主流的基于Java/J2EE的系統中都可以找到，如JavaBean和EJB的home以及remote類，它甚至提供某些專有信息：如Borland EnerPRise Server,JBoss, Orion, Resin, Sun Java System application Server,Weblogic和Websphere。它也支持許多其它技術，如Hibernate, JDO(Java數據對象)，和Castor。假如這些還不夠，XDoclet還可以擴展，答應開發者創建自己的定制標記來生成自制代碼。使用XDoclet，讓它為你生成代碼，你可以在重復的編碼中避免代碼錯誤和bug。
　　
　　代碼度量：可維護性
　　
　　因為代碼容量過大，所以做不到可視地監控整個代碼庫。不必把每一行都過一遍，度量可確認出存在或潛在的問題。Eclipse的Metrics插件是一個開源的，免費的工具，它可以每一個類，每一個包或者每一個項目級別上生成度量值。為了便于保存歷史記錄，結果會輸出在一個xml文件中。它也包含了一個Ant任務，可以用它來生成上述XML。
　　
　　Eclipse的Metrics插件提供了超過23種類型的度量。最重要的一些度量包括接口的數量，深度繼續樹，重載的方法數量，McCabe的三級復雜度，傳入藕合，傳出藕合和抽象。默認地，Metrics圖用藍色顯示合適，用紅色顯示違規。任何顯示紅色的部份都代表了一個可能的問題，需要你回頭確認。插件有它自己的視圖，并在后臺運行;這樣，它不可以被團隊領導者在階段結束時使用，也可以被開發人員用于自己的代碼。
　　
　　代碼覆查：可維護性
　　
　　代碼覆查是一種有效的練習可以用來確保代碼質量，也可以用來在編碼風格和編碼的最佳實踐方面指導開發者。Jupiter是一個開源的，免費的工具，可以進行基于團隊的代碼覆查。Jupiter使用XML文件來跟蹤單個的團隊成員覆查，覆查使用一個覆查ID和覆查者ID(覆查ID是被團隊覆查所共享的)。這些文件被加入到源代碼控制中并對其它開發者可用，答應同步的進行多個覆查，并不需要服務端治理。
　　
　　每個團隊成員使用一個XML文件來從源碼控制中檢入檢出，來看一下什么東西需要整理或者其它成員已完成的整理。使用Jupiter可以免除通常在新開發中要嚴格遵守的bug跟蹤制度。Jupiter把隊員解放了，他們可以在他們方便的時候進行代碼覆查，而不是強迫他們正在解決一個問題時還去參加代碼覆查會議。
　　
　　堅持標準：可維護性
　　
　　開發標準存在的目的是避免過去的錯誤重犯。另外，它也確保了代碼的一致性和對于將來會維護這些代碼的人員的更大的可讀性。Eclipse內置了一個遵循Java編碼約定的格式化器。雖然這很棒，但一個格式化器對于確保產出高質量的代碼是不夠的。
　　
　　Checkstyle建于Eclipse的代碼格式化的基礎之上，增加了更多的語法檢查。它能夠指出不合式的代碼塊，編碼錯誤，重復代碼和一些測量違規。更好的是，CheckStyle是完全可定制的，答應用戶裁剪檢查的類型和組織內部開發標準的嚴格等級。默認的Checkstyle配置文件是全面的。甚至，我建議開發者投資一點時間在定制這個插件上面，讓它完全符合組織的開發需要。定制完成后，Checkstyle的配置文件可以被導出，用到多個項目中。Checkstyle的執行結果是顯示為問題視圖，它能被過濾和分類。結果可以按文件夾，工作集或者源文件級查看，可以讓開發者看到整個編碼，子系統或者單個類的質量。
　　
　　假如你的團隊正中進行Web服務的開發，那么WSVT(Web服務驗證工具)是一個必須的插件。WSVT可以確認一個Web服務是否符合WS-I（Web服務交互）的基本規范。開發者中需右鍵點擊在一個WSDL(Web服務描述語言)文件上，它就可以對WSDL進行驗證，并生成一個可定制的視圖報告，來顯示出現的沖突。作為額外的好處，WSVT插件監控TCP/IP通訊并且觀察、捕捉和驗證SOAP消息。WSVT插件因此可以確保接口層和消息層的合規性。
　　
　　功能測試：可靠性
　　
　　Eclipse集成了Ant和JUnit。Ant是創建基于Java的應用的實事上的工業標準。JUnit基于Java的生成單元測試的框架。
　　
　　開發者可以建立在Eclipse中運行的單獨的JUnit測試，它為JUnit的運行結果提供了非凡的視圖，或者使用Ant的JUnit或JUnitReport任務。JUnitReport Ant任務生成一個可視化的Html報告，它可以根據定制來代表整個系統的測試或者某一個測試。HTML報告是一種非常好的報表，它可以服務測量項目的質量，可以作為歷史記錄保存。使用JUnit進行單元測試，開發者必須確定他們的方法符合他們的聲明，這樣就避免了不規范導致的bug的升級。
　　
　　代碼覆蓋：可靠性
　　
　　當開發者寫了單元測試，他們必須了解這些單元測試提供了大程度的代碼覆蓋。

上一篇：什么是AOP系列之二：AOP與權限控制實現

下一篇：實現J2EE中的多字節字符處理(組圖)