前車之覆，后車之鑒 --開源項目經(jīng)驗談

2019-11-18 13:06:06

字體：大中小

供稿：網(wǎng)友

　　隨著開源文化的日益普及，“參與開源”似乎也變成了一種時尚。一時間，似乎大家都樂于把自己的代碼拿出來分享了。就在新年前夕，我的一位老朋友、一位向來對開源嗤之以鼻的J2EE架構(gòu)師竟然也發(fā)布了一個開源的J2EE應(yīng)用框架（姑且稱之為“X框架”），不得不令我贊嘆開源文化的影響力之強大。
　　
　　可惜開源并非免費的午餐，把源碼公開就意味著要承受眾目睽睽的審閱。僅僅幾天之后，國內(nèi)幾位資深的J2EE架構(gòu)師就得出一個結(jié)論：細看之下，X框架不管從哪個角度都只能算一個失敗的開源項目。究竟是什么原因讓一個良好的愿望最終只能得到一個失敗的結(jié)果？本文便以X框架為例，點評初涉開源的項目領(lǐng)導(dǎo)者常犯的一些錯誤，指出投身開源應(yīng)當(dāng)遵循的一些原則，為后來的開源愛好者掃清些許障礙。
　　
　　成熟度
　　
　　打開X框架在SourceForge的項目站點，我們馬上可以看到：在“Development Status”一欄赫然寫著“5 ? PRodUCtion/Stable”。也就是說，作者認為X框架已經(jīng)成熟穩(wěn)定，可以交付用戶使用。那么，現(xiàn)在對其進行評估便不應(yīng)該有為時過早之嫌。可是，X框架真的已經(jīng)做好預(yù)備了嗎？
　　
　　打開從SourceForge下載的X框架的源碼包，筆者不禁大吃一驚：壓縮包里真的只有源碼??編譯、運行整個項目所需的庫文件全都不在其中。從作者自己的論壇得知，該項目需要依靠JBoss、JDOM、Castor、Hibernate等諸多開源項目，筆者只好自己動手下載了這些項目，好一番折騰總算是在Eclipse中成功編譯了整個項目。
　　
　　不需要對開源文化有多么深刻的了解，只要曾經(jīng)用過一些主流的開源產(chǎn)品，你就應(yīng)該知道：一個開源軟件至少應(yīng)該同時提供源碼發(fā)布包和二進制發(fā)布包，源碼包中至少應(yīng)該有所有必需的依靠庫文件（或者把依靠庫單獨打包發(fā)布）、完整的單元測試用例（對于java項目通常是Junit測試套件）、以及執(zhí)行編譯構(gòu)建的腳本（對于Java項目通常是Ant腳本或者Maven腳本），但這些內(nèi)容在X框架的發(fā)布包中全都不見蹤影。用戶假如想要使用這個框架，就必須像筆者一樣手工下載所有的依靠庫，然后手工完成編譯和構(gòu)建，而且構(gòu)建完成之后也無從知曉其中是否有錯誤存在（因為沒有單元測試）。這樣的發(fā)布形式，算得上是“Production/Stable”嗎？
　　
　　開源必讀：便捷構(gòu)建
　　
　　開源軟件應(yīng)該提供最便捷的構(gòu)建方式，讓用戶可以只輸入一條命令就完成整個項目的編譯、構(gòu)建和測試，并得到可運行的二進制程序。對于Java項目，這通常意味著提供完整的JUnit測試套件和Ant腳本。你的潛在用戶可能會在一天之內(nèi)試用所有類似的開源軟件，假如一個軟件需要他用半天時間才能完成構(gòu)建、而且還無從驗證正確性、無從著手編寫他自己的測試用例，這個軟件很可能在第一時間被扔到墻角。
　　
　　從SourceForge的項目頁面可以看到，X框架的授權(quán)協(xié)議是Apache License V2.0（APL）。然而在它的發(fā)布包中，筆者沒有看到任何形式的正式授權(quán)協(xié)議文本。眾所周知，SourceForge的項目描述是可以隨時修改的（X框架本身的授權(quán)協(xié)議就曾經(jīng)是GPL），假如發(fā)布包中沒有一份正式的授權(quán)協(xié)議文本，一旦作者修改了SourceForge的項目描述，用戶又該到哪里去尋找證據(jù)支持自己的合法使用呢？
　　
　　在X框架的源碼中，大部分源文件在開始處加上了APL的授權(quán)聲明，但有一部分源碼很是令人擔(dān)心。例如UtilCache這個類，開始處沒有任何授權(quán)聲明，而JavaDoc中則這樣聲明作者信息：
　　
　　@author　　 <a href="mailto:[email protected]">David E. Jones</a>
　　
　　也就是說，這個類的源碼來自另一個開源項目Ofbiz。值得一提的是，Ofbiz一直是“商業(yè)開源”的倡導(dǎo)者，它的授權(quán)協(xié)議相當(dāng)嚴格。凡是使用Ofbiz源碼，必須將它的授權(quán)協(xié)議一并全文復(fù)制。像X框架這樣復(fù)制Ofbiz源碼、卻刪掉了授權(quán)協(xié)議的行為，實際上已經(jīng)構(gòu)成了對Ofbiz的侵權(quán)。
　　
　　另外，作者打包用的壓縮格式是RAR，而這個壓縮格式對于商業(yè)用戶是收費的。對于一個希望在商業(yè)項目中應(yīng)用的框架項目來說，選擇這樣一個壓縮格式實在算不得明智。而且筆者在源碼包中還看到了好幾個.jbx文件，這是JBuilder的項目描述文件。把這些JBuilder專用的文件放在源碼包中，又怎能讓那些買不起或是不想買JBuilder的用戶放心呢？更何況，出于朋友的關(guān)心，筆者還不得不擔(dān)心X框架的作者是否會收到Borland公司的律師信呢。
　　
　　開源必讀：授權(quán)先行
　　
　　在啟動一個開源項目時，第一件大事就是要確定自己的授權(quán)協(xié)議，并在最醒目的地方用最正式的方式向所有人聲明??當(dāng)然，在此之前你必須首先了解各種開源授權(quán)協(xié)議。譬如說，GPL（linux采用的授權(quán)協(xié)議）要求在軟件之上的擴展和衍生也必須繼續(xù)GPL，因此這種協(xié)議對軟件的商業(yè)化應(yīng)用很不友好；相反，APL則答應(yīng)用戶將軟件的擴展產(chǎn)物私有化，便于商業(yè)應(yīng)用，卻不利于開發(fā)者社群的發(fā)展。作為一個開源項目的領(lǐng)導(dǎo)者，對于各種授權(quán)協(xié)議的利弊是不可不知的。
　　
　　除了源碼本身的授權(quán)協(xié)議之外，軟件需要使用的類庫、IDE、解壓工具等等都需要考慮授權(quán)問題。開源絕對不僅僅意味著“免費使用”，開源社群的人們有著更加強烈的版權(quán)意識和法律意識。假如你的開源軟件會給用戶帶來潛在的法律麻煩，它離著被拋棄的命運也就不遠了。
　　
　　可以看到，不管從法律的角度還是從發(fā)布形式的角度，X框架都遠夠不上“Production/Stable”的水準(zhǔn)??說實在的，以它的成熟度，頂多只能算是一個尚未計劃周全的開源項目。雖然作者在自己的網(wǎng)站上大肆宣傳，但作為一個潛在的用戶，我不得不冷靜地說：即便X框架的技術(shù)真的能夠吸引我，但它遠未成熟的項目形態(tài)決定了它根本無法在任何有實際意義的項目中運用。要讓商業(yè)用戶對它產(chǎn)生愛好，作者需要做的工作還很多。
　　
　　我剛才說“即便X框架的技術(shù)真的能夠吸引我”，這算得上是一個合理的假設(shè)嗎？下面，就讓我們進入這個被作者寄予厚望的框架內(nèi)部，看看它的技術(shù)水平吧。
　　
　　整體架構(gòu)
　　
　　在X框架的宣傳頁面上，我們看到了這樣的宣傳詞：
　　
　　X框架解決了以往J2EE開發(fā)存在的諸多問題：EJB難用、J2EE層次復(fù)雜、DTO太亂、Struts繞人、緩存難做性能低等。X框架是Aop/Ico[注：應(yīng)為“IoC”，此處疑似筆誤]的實現(xiàn)，優(yōu)異的緩存性能是其優(yōu)點。
　　
　　下面是X框架的整體架構(gòu)圖：
　　前車之覆，后車之鑒 --開源項目經(jīng)驗談

　　可以看到，在作者推薦的架構(gòu)中，EJB被作為業(yè)務(wù)邏輯實現(xiàn)的場所，而POJO被用于實現(xiàn)Fa?ade。這是一個好的技術(shù)架構(gòu)嗎？筆者曾在一篇Blog中這樣評價它[1]：
　　
　　讓我們先回想一下，使用EJB的理由是什么？常見的答案有：可分布的業(yè)務(wù)對象；聲明性的基礎(chǔ)設(shè)施服務(wù)（例如事務(wù)治理）。那么，假如在EJB的上面再加上一層POJO的Fa?ade，顯然你不能再使用EJB的基礎(chǔ)設(shè)施了，因為完整的業(yè)務(wù)操作（也就是事務(wù)邊界）將位于POJO Fa?ade的方法這里，所以你必須重新??以聲明性的方式??實現(xiàn)事務(wù)治理、安全性治理、remoting、緩存等基礎(chǔ)設(shè)施服務(wù)。換句話說，你失去了 session bean的一半好處。另一方面，“可分布的業(yè)務(wù)對象”也不復(fù)存在，因為POJO本身是不能??像EJB那樣??分布的，這樣你又失去了session bean的另一半好處。
　　
　　繼續(xù)回想，使用基于POJO的輕量級架構(gòu)的理由是什么？常見的答案有：易于測試；便于移植；“開發(fā)-發(fā)布”周期短。而假如僅僅把POJO作為一層Fa?ade，把業(yè)務(wù)邏輯放在下面的EJB，那么你仍然無法輕易地測試業(yè)務(wù)邏輯，移植自然也無從談起了，并且每次修改EJB之后必須忍受漫長的發(fā)布周期。即便是僅僅把EJB作為O/R mapping，而不是業(yè)務(wù)邏輯的居所，你最多只能通過DAO封裝獲得比較好的業(yè)務(wù)可測性，但“修改-發(fā)布”的周期仍然很長，因為仍然有entity bean存在。也就是說，即使是往最好的方面來說，這個架構(gòu)至少損失了輕量級架構(gòu)的一半優(yōu)點。
　　
　　作為一個總結(jié)，X框架即便是在使用得最恰當(dāng)?shù)那闆r下，它仍然不具備輕量級架構(gòu)的全部優(yōu)點，至少會對小步前進的靈敏開發(fā)造成損害（因為EJB的存在），并且沒有Spring框架已經(jīng)實現(xiàn)的基礎(chǔ)設(shè)施（例如事務(wù)治理、remoting 等），必須重新發(fā)明這些輪子；另一方面，它也不具備EJB的任何優(yōu)點，EJB的聲明性基礎(chǔ)設(shè)施、可分布業(yè)務(wù)對象等能力它全都不能利用。因此，可以簡單地總結(jié)說，X框架是一個這樣的架構(gòu)：它結(jié)合了EJB和輕量級架構(gòu)兩者各自的短處，卻拋棄了兩者各自的優(yōu)點。
　　
　　在不得不使用EJB的時候，一種常見的架構(gòu)模式是：用session bean作為Fa?ade，用POJO實現(xiàn)可移植、可測試的業(yè)務(wù)邏輯。這種模式可以結(jié)合EJB和POJO兩者的優(yōu)點。而X框架推薦的架構(gòu)模式，雖然乍看起來也是依葫蘆畫瓢，效果卻恰恰相反，正可謂是“取其糟粕、去其精華”。
　　
　　開源必讀：架構(gòu)必須正確
　　
　　在開源軟件的初始階段，功能可以不完善，代碼可以不漂亮，但架構(gòu)思路必須是正確的。即使你沒有完美的實現(xiàn)，參與開源的其他人可以幫助你；但假如架構(gòu)思路有嚴重失誤，誰都幫不了你。從近兩年容器項目的更迭就可以看出端倪：PicoContainer本身只有20個類、數(shù)百行代碼，但它有清楚而優(yōu)雅的架構(gòu)，因此有很多人為它貢獻外圍的功能；Avalon容器盡管提供了完備的功能，但架構(gòu)的落伍迫使Apache基金會只能將其全盤廢棄。
　　
　　所以假如你有志于啟動一個開源項目（尤其是框架性的項目），務(wù)必先把架構(gòu)思路拿出來給整個社群討論。只要大家都認可你的架構(gòu)，你就有機會得到很多的幫助；反之，恐怕你就只能得到無盡的嘲諷了。
　　
　　技術(shù)細節(jié)
　　
　　既然整體架構(gòu)已經(jīng)無甚可取之處，那么X框架的實現(xiàn)是否又像它所宣稱的那樣，能夠解決諸多問題呢？既然X框架號稱是“AOP/IoC的實現(xiàn)”，我們就選中這兩項技術(shù)，看看它們在X框架中的實現(xiàn)和應(yīng)用情況。
　　
　　IoC
　　
　　X框架宣稱自己是一個

上一篇：如何使用Lucene對html文件進行索引

下一篇：Web App用Quartz實現(xiàn)java schedule job