前車之覆，后車之鑒 --開源項目經驗談

2019-11-18 13:06:06

字體：大中小

來源：轉載

供稿：網友

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

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

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

下一篇：Web App用Quartz實現java schedule job