【51CTO.com獨家特稿】嘉賓介紹

　　羅果是Tiny開源框架創始人，主要關注技術領域為J2EE及應用開發平臺，涉獵廣泛。他在模塊化、元數據、模板引擎、數據庫分區分表、SOA等領域有較深入實踐，吃過N多的虧，上過N多的當，當然也積累了N多的經驗。

[[147964]]

　　在業余時間，羅果熱心于參與開源軟件相關工作，在進行軟件開源的同時，也編寫了大量的技術博客，從問題、原理、實踐方面進行了深入淺出的講解。

　　他經常掛在嘴邊一句話是：好的軟件設計是“品”出來的。信奉好的軟件架構一定是簡單的。

　　下面是羅果先生回答51CTO小編的幾個問題，我們整理出來以饗讀者。

　　1.開發TinyFramework的初衷是什么?

　　我在開發TinyFramework之前，也在公司的體制下主導了開發平臺的開發，但是由于在公司體制下，需要完全按照公司的要求和規范來開發，實際上就要顧及各方面的平衡，而這些平衡可能會對一個框架產生嚴重的傷害。而我期望做一個各方面比較均衡的開發平臺，于是就從各種小的專題性驗證開始，比如：流程化編程、模塊化設計、數據庫分區分表等等一一進行驗證，當驗證的范圍越來越大，涵蓋的領域越來越多的時候，才真正開始決定做一個開源框架。

　　因此，追本溯源，最初的初衷就是對自己思想的一些驗證。

　　2.前段時間TinyFramework剛推出 2.0 版本，新的版本里有哪些新的特性?在一年的開發中，有哪些值得記錄的故事?

　　TinyFramework的立意是企業級的開發平臺，因此在方法論、設計理念、開發體系、設計原則、生態圈、模塊化、熱部署、水平擴展、元數據等非功能性要求方面做了大量的探索和實踐。

　　當然在功能性需求方面，也有非常多的突破，由于Tiny框架涵蓋的功能太多，因此只拿幾個有代表性的功能來簡單介紹一下：

　　◆TinyDBRouter(數據庫分區分表)：基于JDBC層實現，可以支持SQL92規范下的各種數據庫進行透明的數據庫分區、分表讀寫分離等水平擴展。

　　◆TinyTemplate(模板引擎)：一個類 Velocity的模板引擎，但是功能更強大，添加了許多Velocity不支持的特性，運行速率大致是Velocity的4倍。

　　◆TinySqlDSL(數據庫開發框架)：基于領域查詢語言方式的數據庫開發框架，可以在Java中用類似于寫SQL的方式來進行數據庫編程，比較好的解決了數據庫與Java兩層之間結合時的問題(要么兩者是分離的如iBatis，要么引入一種全新的語言如Hibernate的HSQL，要么就是在Java中進行大量的SQL拼接)。當然數據庫的開發方案有許多種解，各種解有各種解的優缺點，DSL方式也是一種實現方案，有其自己的優缺點。

　　◆TinyUI(界面引擎)：主要解決WEB應用開發中的模塊化和JS、CSS及各種靜態資源管理的問題，主要解決靜態資源Jar包化、CSS 合并打包壓縮、JS合并打包壓縮，UI模塊之間的依賴關系等體系性問題。

　　◆TinyStudio(集成開發工具)：提供了可視化界面設計，可視化流程編排、模板引擎編輯器、代碼生成器，服務編輯器、元數據編輯器、數據庫設計器。

　　3.你平常是怎樣維護TinyFramework項目和社區的?

　　在早期，我們還是默默無聞的，因為我們不想在框架還是一個半成品的時候就拿出來，直到我們已經開發完畢并且在項目組內進行了充分驗證的時候才真正地在社區或相關網站進行發布。我們大致是從以下幾個角度維護項目和社區的：

　　◆代碼托管在開源中國的git倉庫：https://git.oschina.net/tinyframework/tiny。目前有294 watches，453 stars，361 forks。

　　◆構建Tiny文檔WiKi：http://www.tinygroup.org/confluence/display/TF。Tiny文檔總共有900多頁，涵蓋了設計、實現、示例、實踐等各方面，目前日訪問量在1500左右。

　　◆創建Tiny社區：http://bbs.tinygroup.org。Tiny社區是新推出的專注入Tiny方面的交流與溝通平臺。

　　◆創建Tiny交流QQ群：228977971。QQ群采取比較嚴格的管理方式，對技術純潔性保持良好。目前該群已有用戶1000多人。

　　通過上面的一些與項目相關的社區、博客、QQ群等形式，我們與廣大Java框架、Tiny愛好者進行了充分的互動與交流。不管是學習者、參與者、交流者、使用者，希望大家都有收獲。同時，在這個過程中，我們也受益匪淺，對開源項目也有了更深入的理解。

　　4.TinyFramework有哪些優點和特點?有沒有哪些特殊的或者創新的技術運用?

　　◆設計理念決定了設計的目標

　　使用靈活：可以整個使用它，也可以只用它的一個或幾個部分。Tiny構建者認為，一個完整的框架可能需要由許多個部分組成，但是對于實際應用的用戶來說，它可能只需要其中的一部分功能。框架一定要有這種能力，可以由使用者進行菜單式使用，避免只要用一點點功能，就要引入許多其他的功能。

　　學習成本低、上手容易：框架的學習成本必須非常低，才可以讓使用者更容易上手，避免由于學習難度大而導致的學習曲線太陡、太長。

　　保持核心的穩定性：Tiny框架要求在穩定、安全要求非常高的應用環境中使用，因此其穩定性就是框架構建者首要思考的目標，核心部分只使用經過充分驗證及廣泛應用的第三方包。

　　資產的可積累性：只有易于知識積累，才可以真正做到越用越強。

　　◆設計原則解決目標沖突時的解決策略

　　約定優于配置原則-COC

　　不要重復你自己原則-DRY

　　減法原則 ：減法原則是我們自己提出的，意思就是給程序員做減法。

　　模塊化原則：模塊化對于軟件開發過程中的開發、高度、集成、發布、維護過程中所起的作用是節省可能要花費的大成本。因此，我們提出了Business Unit的概念，使得與模塊相關的所有內容可以放在一塊。

　　自動組裝原則：在整個Tiny框架的構建過程中，都非常注重集成過程的自動組裝，要求做到用戶使用起來不用管，由框架自動集成。

　　下級服從上級原則：Tiny框架從框架層級做了限制，使得下級必須服務上級。

　　單一原則：通過單一原則進行強制性的約束，使得一個模塊只解決單一模塊應該解決的問題，從而避免不同的問題放在一起解決所導致的混合問題，同時也避免了不恰當的依賴及模板引用。

　　集中配置原則：我們對Tiny框架配置做了大量的工作，一個是COC方式，如果您不進行配置，可以采用系統默認的值;一個是集中原則，把需要人工配置的內容集中起來做統一配置;一個是對不需要人工干預的配置，那就集成在Jar包中，作為發布者發布項的一部分。

#p#

　　◆一些創新性的技術應用

　　SOA：Tiny的服務是一次開發到處使用，也就是一旦完成了服務的開發，你可以用RMI，WebService，Json，Xml等等，或者其他你想不到的方式進行服務調用。

　　服務水平擴展能力：在遵守Tiny開發規范的前提下，可以方便的進行接入和服務層的水平擴展。也就是說當你的處理能力不足的時候，只要加一臺機器就可以增加處理能力，而不必對現有運行的環境進行任何變化。

　　模塊化技術：Tiny模塊化的設計思想是全部都可以進行模塊化，也就是所有的文件都可以放在Jar包中，甚至連Jsp也可以放入Jar包。通過模塊化技術，我們可以方便的進行模塊分隔與復用。

　　自組裝技術：Tiny的自組裝設計思想是所有的模塊都可以做到加入即可用，去除就消失。也就是說，如果你用別人的一個組件，你只要通過Maven依賴它即可以;如果你不想用了，取消Maven依賴即可。這樣就會大大減少集成相關的工作量。

　　熱部署技術：關于熱部署的實踐有許多種，比如OSGI，但是不管哪一種，都有一定的強依賴性，或者說是侵入性。Tiny的熱部署實現機制則簡單的多，只要按照正常的方式來開發Jar包，并且配置一個Bundle聲明文件即可。實際應用當中，既可以按照Bundle機制運行，也可以按照普通Jar包來運行。

　　UIML技術：UIML也就是統一界面描述語言的意思。通過這一特性，再加上配套的可視化界面設計工具，就可以實現一次開發到處使用的界面開發目標。

　　AOP緩沖框架：可以有效剝離緩沖與業務代碼，可以透明的切換緩沖方案，大幅降低緩沖相關代碼編寫的開發與重構成本。

　　文檔生成框架：按照Tiny開發規范進行開發，許多的文檔都可以通過工具自動化生成。文檔與代碼不一致不再是問題，同時還可以節省大量的文檔編寫時間。

　　5.目前TinyFramework使用情況如何?成功的應用案例可以和我們分享下嗎?

　　TinyFramework從初版出來，目前主要在公司內部進行推廣和應用。同時，已經有許多企業級和互聯網級產品基于Tiny開發，并在幾十家客戶中使用。產品開源以來，許多團隊或者企業在應用過程中提出了許多好的意見、建議和需求，有的甚至直接幫我們提交了Pull Request。一年以來，Tiny的社區環境越來越完善，期望在2015年，TinyFramework能夠在外部用戶數上有一個較大的提升。

　　6.能否稍微介紹一下你們的開發團隊?你們平時都是怎樣進行溝通協作的?

　　TinyFramework的開發團隊由穩定的團隊成員組成。我也嘗試過招募一些愿意參與的愛好者，實際執行效果不太好，當然原因也是各方面的，我也非常理解沒有堅持下來的參與者。

　　團隊成員的溝通方式主要有如下幾種：

　　◆團隊建設：上一年當中，大家一塊吃飯討論有20多次。吃飯的理由很多，比如家里添丁、技術晉級、產品獲獎等，當然最多的聚餐理由是由于出現嚴重Bug，或者有嚴重的設計缺陷、提交了影響開發的代碼等技術相關的理由。大家邊吃邊聊又提升了技術能力，同時也讓大家認識到這種類型的錯誤根由，保障下次不再出現類似問題。

　　◆GIT中的Issues：團隊有句口頭禪，嘴巴講的不算。不管是需求還是Bug，都要錄入到Issues當中，由各管理員統一進行協調管理。提出問題、批注問題、解決問題、跟蹤問題、關閉問題，都要在Issues當中進行管理。

　　不論是線上還是線下的交流，對于我們的團隊協作與和諧發展都起了非常大的作用，互為補充。

　　7.你能否談談你對開源的理解以及國內開源技術和產品的看法?

　　這個問題有點大，就拿我以前寫的一篇博文中的內容來回答我對開源的理解。

　　關于收入的問題，如果期望開源能夠快速給自己帶來收入，絕大多數可能會失望。一般來說，一個開源產品，從開始，到發展，到能盈利，***實現營收平衡，這是一個漫長及艱難的過程。

　　那開源不關心收入，為什么還要開源呢?我想可能有如下可能：

　　◆獲取精神上的滿足

　　比如，你做了一個好東西，但是前期賣不了錢，放在自己這里，沒有太多成就感。如果拿出來開源，讓大家可以使用，開發者會獲得一些成就感。

　　◆獲得社會的認可

　　通過開源，獲得相當的社會認可度，獲得與別人合作的機會，更可能贏得更好的發展或工作機會也說不定。

　　◆收集需求

　　一個人在那里做，總是有這樣那樣的局限。即使你是超級牛人，通過給別人免費使用，別人給你提出各種意見和建議，可以幫你快速豐富和完善產品。

　　◆用戶測試

　　有時候，你做了個東東，自己也不知道到底好不好，現在有許多用戶來使用，實際上在幫你做測試。

　　◆獲取用戶群

　　有時候，一個產品放在那里沒有什么價值，但是隨著用戶群越來越大，可能就有盈利的潛質了。同時也是對潛在用戶的培育，免費使用的人多了，可能就有愿意付費獲得更好的服務與產品或者定制開發的人了。

　　◆一種市場營銷手段

　　本來產品本身做的不錯，通過開源，獲得市場認可，提高知名度，為后續推廣奠定基礎;同時讓人們看到內部的實現，從黑盒變成白盒，讓人們放心的選擇。

　　當然也可能是其中的幾個或者全部。總之，開源是一個艱辛的選擇，需要長久的堅守，需要不急不燥的一份態度。

　　所以，開源是一種修行，你在這個階段中，可能是沒有成果的凡人，也可能是小有成就的佛子，更有可能是大有成就的尊者，甚至是至真至高的佛。

　　接下來回答國內開源技術和產品的看法：

　　實際上，開源項目的發展也是符合螺旋式的軌跡，整體來看，國內對開源的認識也在由拿來免費用的初級理解向更高級別的層次發展。從整體來看，國人開源的技術和產品相對還處在一個初級階段，比如：僅僅是把代碼開放出來，沒有后續的社區建設，也沒有形成生態圈等各種局限。但是由于國內的開源產品基數大，我們可以看到越來越多的優秀開源者和開源產品涌現出來，這也符合量變引起質變的客觀規律。Tiny框架與這些優秀開源產品相比，還比較稚嫩，還有非常大的差距，不過我們相信，只要能切實踐行我們團隊的格言“Think big, start small, scale fast!”，我們就一定會成為優秀的開源產品之一。

　　歡迎大家多關注我們的Tiny社區：http://bbs.tinygroup.org。有關Tiny的話題，歡迎加入QQ群：228977971。