子產品化的Javascript庫 —— Tangram
Tangram是一個适用面廣、高度子產品化的Javascript庫。内含大量基礎方法與Javascript元件，開發人員能基于它便捷地完成開發工作。本文将介紹Tangram的曆史、設計原理和系統架構，旨在幫助各位讀者更好地了解Tangram。
曆史
要了解Tangram的使用場景和設計思想，需要從Tangram的曆史淵源說起，其實這也是百度Web前端庫的發展史。
05 － 07年，百度前端處于洪荒年代，沒有Javascript庫，僅在部門wiki中存在一些函數積累，工程師開發時，copy-paste以後稍作修改便成為産品的一部分。
07年起，部分産品逐漸開始基于開源庫（prototype，YUI等）進行修改，形成産品内部的JS庫，積累也逐漸增多。但是開源庫的功能相對百度的需求都過于複雜，體積龐大，部門内出現需要百度Javascript庫的呼聲。
08年初，一些有想法的工程師利用項目閑暇時間，整理編寫第一個通用Javascript庫 —— FE，FE庫在百度社群類産品線得到了較廣泛的使用，從那時起逐漸形成了子產品化、無侵入的設計思想。
09年6月，由于FE庫沒有固定的維護人員，同時在接口組織，可維護性上還有很大的提升空間，經過讨論，決定基于公司内多個Javascript庫，由專人負責，開發出一個新的類庫。于是我們有了Tangram這個全新的基礎庫，經過一年多時間發展，Tangram已經包含開發中大多數常用的功能與元件，成為了百度應用最廣泛的Javascript庫。
10年12月底，Tangram正式開源，現已正式釋出兩部分。一部分是基礎庫，包含DOM操作，ajax等基礎功能，另一部分是元件庫，包含大量可重用的ui控件以及動畫效果等。除此之外，我們還基于Tangram開發了線上編輯器，無線庫等子項目。
設計原理
七巧闆 —— Tangram的中文名 ，這是一個古老、簡單的子產品化系統。Tangram庫正如七巧闆一樣，它的核心設計思想就是子產品化。
子產品粒度小
在國内，由于網際網路的連接配接速度仍然比較慢，同時使用者的計算機與浏覽器相對老舊，是以前端開發人員一直都很關注帶寬占用和加載速度。市面上的Javascript庫，最小的子產品一般是一組功能方法（如DOM操作的相關方法）或者一個元件（如對話框）。開發人員在選擇時存在一個兩難問題：如果庫體積精簡，二次開發量就大，如果庫功能豐富，就會有備援代碼。
為解決這個問題，Tangram采用了更小的子產品拆分。在Tangram基礎庫中，每一個函數方法是一個獨立的子產品；在ui元件中，最小的子產品機關是元件插件。開發人員通過線上代碼選擇功能，獲得定制後的Tangram放入自己的産品中。
是以，Tangram能夠不斷補充功能子產品，而使用者始終能按照需求，獲得體積最精簡的代碼，這在功能豐富與體積精簡之間達到了平衡。同時，每一個子產品都是獨立而且簡單的，開發人員也可以很友善的對其進行研究，了解原理進而更好的使用。
【圖1】Tangram的代碼選擇功能界面
易于封裝、擴充
Tangram面向的産品跨度廣，光是百度内部就有搜尋産品，社群産品，商業産品三大系列。不同的産品對Javascript庫的要求也不盡相同：搜尋産品要求體積精簡，社群産品希望使用友善，商業産品看重功能齊全。
很顯然，Tangram不可能直接滿足所有産品的需求，隻能在封裝和擴充的便利性上下功夫。首先，基礎庫中大多是靜态方法，對封裝十分友好。而在元件庫中，提供了元件插件、公用行為等機制，讓使用者可以很友善的擴充出自己想要的功能元件。使用者很友善的就能基于Tangram，選擇合适的子產品，封裝一套符合産品自身特點的Javascript庫和一個個獨立的功能元件。
當然，在Tangram内部，也會利用這個特性完成一些較高層次的封裝。如将DOM和Event封裝成Element，提供鍊式調用功能。
無侵入式設計
在面對多年前的遺留系統，或者含有第三方Javascript代碼的系統時，總能看到頁面上泛濫着各種全局變量，或者對prototype的修改，甚至會存在同一個Javascript庫的不同版本。開發者常常會因為代碼之間的互相沖突而煩惱不堪。
為了最大程度的避免沖突和污染，Tangram僅僅暴露一個變量到目前作用域，使用者完全可以把Tangram放在閉包中使用，這樣即使頁面上含有兩套不同版本的Tangram，他們之間也不會有任何沖突。同樣的，元件庫也采用了無污染的設計，不會對頁面上的現有DOM元素、業務代碼産生影響。
系統架構
Tangram從一開始就緻力實作一個結構清晰、層次分明的系統。系統結構如下：
【圖2】Tangram系統架構圖
基礎庫
Tangram底層是基礎庫，包括18個功能包，如DOM，event，ajax，page等，滿足開發中對基礎方法的需求。基礎庫被分做兩部分：core和extra，core是常用方法，gzip壓縮後體積尚不足10K，extra則是其餘不夠常用的方法，這是統計了使用者對接口的依賴程度後進行的劃分。
為保證基礎庫方法的精簡，所有基礎庫方法一律不做參數檢查，由調用者或者二次封裝自行保證。此外，整個Tangram庫都有很強的一緻性，同類的方法接口命名和參數形式都很一緻。
元件庫
元件庫在基礎庫之上，其中又以UI元件結構較為複雜。所有的21個UI元件都是基于UI Base開發的，UI Base實作了UI元件的統一建立，插件與行為機制，代碼也足夠精簡，gzip壓縮後體積僅1K。
UI元件的插件與行為
正如前文所述，元件的功能豐富和體積精簡之間存在沖突。特别是在産品不需要元件的某些内置功能時，那部分代碼就成為了累贅。為了調和這種沖突，Tangram在UI體系中采用了插件機制。每個UI元件都被拆分成了一個小巧的UI核心，與一組功能獨立的插件。
UI核心僅完成資料結構定義，控件DOM結構和其他控件基本功能，所有非必須功能都由插件提供。插件可以在代碼選擇時，由使用者根據需要，自由選擇。如對話框核心僅僅完成對話框的建立、開啟、關閉與更新，由插件提供拖拽、縮放大小、鍵盤支援、模态窗體等附加功能。
此外，針對UI元件間的共同點，我們抽取出了UI behavior，UI行為能被自由的添加到任何元件上，這個附加動作甚至可以來自使用者調用，如将draggable行為附加到元件上以後，元件就擁有了拖拽行為。
開發、釋出過程
Tangram現在由專門的團隊負責開發和維護，為了保證庫的持續發展，一套嚴格、可遵守的開發流程是關鍵。Tangram的開發分四個階段：
調研、接口設計：調研使用場景與問題來源，同時參考同類元件，完成功能定義與接口設計，供小組評審。如果功能較複雜，需要提供一個完成基本功能的Demo，用于驗證設計的正确性。
開發：完成代碼，手動測試用例與基礎自動用例，基礎庫子產品采用測試驅動的方式進行開發。
代碼評審：将代碼送出到codereview平台上，全組參與評審，一個子產品一般需經曆2-3輪評審修改。評審完畢後，代碼會被送出至github的dev分支上，由QA編寫完整的自動化測試用例進行測試。
在開發過程中，我們尤其注重設計和代碼評審階段。一般來說，一個子產品的設計時間要占到整個開發周期的50%以上，而代碼評審時間在30%左右。值得一提的是，注釋在Tangram中占有很重要的地位，所有API文檔都是通過注釋生成，是以在代碼評審時，也會重點關注注釋的準确性和完整度。
當dev分支上的功能累積達到roadmap目标，進入釋出階段。由釋出負責人review所有新增功能與bug修複，整理changelog，同時QA負責人确認自動化用例的覆寫率，進行完整回歸。測試完畢後，會将相應代碼合并到master分支，打上版本tag。
文檔與源碼
如果你想更多的了解Tangram，或者參與Tangram的讨論或者開發，請關注下文網址：
線上文檔：http://tangram.baidu.com
貼吧讨論區：http://tieba.baidu.com/tangram
基礎庫源碼：https://github.com/BaiduFE/Tangram-base
元件庫源碼：https://github.com/BaiduFE/Tangram-component
【本文首發于：百度網際網路技術官方部落格】http://blog.csdn.net/baiduforum/article/details/6213505
【關注百度技術沙龍】