近兩年
開放源碼項目發展日益壯大
出現了很多有著廣闊用戶群體的項目與產品
它們在企業應用開發中正在發揮著越來越大的作用
本文以基於J
EE架構的企業應用開發為例
探討了如何在項目中深入運用JAVA開發源碼項目與工具
一企業應用開發目前面臨的主要問題 企業應用是指服務於商業目的
處理企業業務信息
數據的軟件系統
雖然隨著dot COM熱潮逐漸冷卻
企業開始謹慎考慮自己在應用系統開發方面的投入
但是畢竟企業的業務流程需要專門的信息系統處理
從而提高自動化程度
減少中間環節
加快信息處理速度
因此
目前國內的企業應用項目開發還是日益火爆
尤其在電子政務
CRM
SCM等領域更是如此
但是
不論企業應用開發是采用自行開發或者委托系統集成商進行開發
都存在著下面一些情況
大部分項目超時或者超出預算
項目在部署以後BUG很多
而且修改的周期比較長
對於系統集成商來說
下面的情況更是比較普遍
沒有統一的FRAMEWORK
每個項目都會重新設計ARCHITECTURE
項目開發過程的自動化程度和重復步驟不是很多
人為引入的BUG很多
二開放源碼項目現狀 開放源碼運動在
年代開始日益發展
目前已經成為軟件業內不可低估的一股勢力
比較著名的有Linux
Apache
Tomcat
MySQL等
目前
開放源碼的潮流已經超出了操作系統
數據庫管理系統和WEB服務器等系統開發領域
開發在企業應用開發中尋找新的領地
尤其是對於企業應用開發的框架和CASE工具
開放源碼項目都有很優秀的解決方案
國外開放源碼項目的集中地有以及
其中
前者為大家奉獻了著名的Apache
Tomcat
Struts
Axis
而後者是最著名的開源項目中心
同時
國內自
年代末開始也有很多人投入到開源項目的開發
比較集中的網址是
共創軟件聯盟
() 等等
他們除了提供各種CASE工具以外
還有一些項目是專注於特定領域的解決方案開發
如CRM等
三JAVA開發源碼項目與工具的應用 對於目前企業應用開發競爭日益激烈
需求變更頻繁
各個系統集成商都面臨巨大的生存壓力
其中有兩個方面表現尤其突出
沒有統一的軟件開發過程或者照搬重量級的軟件開發過程
例如RUP等
但是往往由於時間等壓力的影響
並不能切實執行
大部分企業仍然沒有擺脫手工作坊期間的做法
每個項目或者產品由於管理人員或者團隊的不同
重新設計系統框架
浪費大量的時間在結構驗證與調整上
企業應用系統的開發中
需求的變更是項目中唯一不變的東西
而且
為了保持開發的一致性和利益最大化
系統集成商需要與客戶保持長期的合作
因此
采取演進式敏捷軟件開發
可以更好的保證項目質量
在所有的敏捷軟件開發方法中
XP是目前應用最為廣泛的一種
它是一種高度動態的過程
它通過非常短的迭代周期來應對需求的變化
溝通
簡單
反饋和勇氣是它的四大核心價值
同時
它集中了業界的很多最佳實踐
目前已經有
條之多
XP強調通過嚴格執行全部的最佳實踐來獲得
極限
效果
同時
出於復用和效率的考慮
尤其是對於系統集成商
企業應用系統應該具有自己的框架和結構
擁有具有良好性能
經過項目驗證的系統框架
結合有效的軟件開發過程
系統集成商可以快速
成功地開發企業應用系統
為了更好的開發成功的系統
系統集成商們可以試著從以下兩個方面著手解決問題
結合開源工具的支持
在組織內部實施
敏捷軟件開發方法
為核心業務領域建立靈活
有效的Framework
由於目前很多企業應用是采用基於J
EE技術的網絡應用程序開發
因此
下面主要介紹基於JAVA的開源項目
工具的應用
開源工具與XP
XP的
條最佳實踐
對於所有的企業應用開發商而言
由於組織和文化的不同
不可能全部應用
但是
下面幾個實踐是有條件逐步實施的
代碼規范
CODE STANDARD
測試驅動開發
TEST
DRIVEN DEVELOPMENT
日構建
DAILY BUILDING
持續集成
CONTINUOUS INTEGRATION
小步發布
SMALL RELEASE
每日晨會
DAILY MEETING
每周
小時工作
HOURS A WEEK
其中
CODE STANDARD和TDD是CONTINUOUS INTEGRATION
DAILY BUILDING和SMALL RELEASE的基礎
而DAILY MEETING和
HOURS A WORK是單獨的實踐過程
可以與其他的實踐想結合
增強項目小組的溝通
激發士氣
需要說明的是以上最佳實踐並非XP所獨有
而是被最多的軟件開發方法所應用
其中
日構建
就在微軟的軟件開發方法中正式出現過
代碼規范
雖然大部分的企業在一定程度上推行代碼標准與規范
而且對於使用JAVA的應用程序開發
也有SUN的推薦編碼規范
但是
實際的情況並不理想
主要的原因在於
一方面
開發人員的習慣勢力很大
另一方面
代碼審查的力度不夠
如果能夠借助工具
從一定程度上幫助進行代碼標准的執行情況檢查
那麼代碼審查就可以著重檢查程序的邏輯和性能等方面
開源產品CheckStyle () 可以幫助開發組織解決代碼標准審查的問題
目前的最新版本為
它提供了兩種運行方式
一種是命令行
一種是與Ant結合(Ant自
以後提供的OPTIONAL TASKS中有對於CheckStyle的支持)
同時
SourceForge中有對於JBuilder等流行IDE的插件支持
可以定義Global
Project級別上的屬性文件
但是
目前只是支持
版本
在
x版本之前
CheckStyle的配置信息寫在Property File中
而在
x之後
配置信息為XML文件
配置更加靈活
的發布版本中提供了針對Sun Code Conventions的特定Check File
可以參考使用
建議執行情況
手動執行
開發人員在IDE中手動觸發CheckStyle檢查或者代碼審查時由審查者手動執行
自動執行
將CheckStyle與源碼控制系統(CVS)結合
在源碼Checkin的時候進行規則判斷
如果不符合
則不允許代碼進入系統
測試驅動開發
測試先行或者測試驅動是XP的基本實踐之一
同時測試在軟件開發中的重要作用正越來越得到人們的重視
審查和測試作為系統確認和驗證的有效方式
是項目質量保證的重要措施
下面按照一般的測試分類
介紹各個領域內的開源測試工具
單元測試
JUnit ()
JUnit是由 Erich Gamma 和 Kent Beck 編寫的一個回歸測試框架（regression testing framework）
用於Java開發人員編寫單元測試之用
下面介紹的開源測試工具
很多都是對於JUnit的擴展
它目前的版本為
為編寫單元測試提供了主要的接口
目前主流的IDE都提供了對於JUnit的支持
XP強調測試先行
尤其重視單元測試
系統集成商需要通過軟件開發過程的執行
來強化JUnit的使用
目前很多商業測試軟件都提供了與JUnit的聯合使用
例如獲得
和
年Jolt測試類工具亞軍和生產率大獎的Jtest (ParaSoft公司產品
內置
余條編碼規范
提供Java代碼靜態和動態檢查
同時還可以自動生成簡單的測試用例等等)就可以導入和導出JUnit的測試用例
集成與功能測試
HttpUnit () & Cactus ()
HttpUnit是一套通過HTTP連接測試Web應用程序的Java類
在結合JUnit的情況下
HttpUnit可以作為一種創建測試程序的強大工具用來保證Web應用程序正常的端對端功能
雖然JUnit自身就可以通過編寫單一類的測試程序對服務器端Java代碼進行測試
不過
有了HttpUnit的幫助
JUnit就可以擴展為模擬Web浏覽器
Web服務器的工作方式對整個Web程序結構進行測試
Cactus為我們提供了一種測試SERVLET等WEB組件的有效手段
它是JUnit的一個擴展
但是它又和JUnit有一些不同
Cactus的測試分為三種不同的測試類別
JspTestCase
ServletTestCase
FilterTestCase
而不是像JUnit就一種TestCase
Cactus的測試代碼有服務器端和客戶端兩個部分
他們協同工作
一般意義上
可以采用Cactus作集成測試
而使用HttpUnit做功能測試
雖然在集成與功能測試方面
有很多優秀的開源工具
但是在實際應用過程中
還是采用商業測試軟件的比較多
對於復雜應用更是如此
這是因為集成與功能測試大部分還是由專門的測試人員進行
而他們對於已有的商業軟件
例如Rational Robot
E
Test Suite
WinRunner等都比較熟悉
同時商業軟件也提供了更為強大的功能
壓力與性能測試
JMeter ()
由於企業應用越來越復雜
用戶數量也是越來越多
系統的性能參數以及眾多的非功能性需求在開發中獲得了越來越多的重視
因此
很多壓力與性能測試工具也開始出現
這其中有一定影響的是Apache Software Foundation的JMeter
JMeter是
%的JAVA桌面應用
用來測試系統的負載與性能
它最開始設計是用來測試WEB應用
後來加以擴展
可以測試Http
FTP
支持JDBC的關系型數據庫的性能與壓力
同時
JMeter提供一定的定制功能
系統集成商可以自行開發針對EJB
CORBA或者SOAP的插件
壓力與性能測試方面
由於測試比較復雜
實際企業應用測試中
也是采用商業測試軟件比較多
例如LoadRunner
JProbe Suite以及與JBuilder
同步發布的OptimizerIT
日構建
在軟件開發
From:http://tw.wingwit.com/Article/program/Java/ky/201311/28003.html
