YUI3在淘寶彩票中的實踐小結

來源:互聯網
上載者:User

導語:春風吹戰鼓擂,YUI3早就扛起了高端的“前端團隊開發”的大旗,昂首闊步的朝我們走來,不管是Yahoo對YUI3的實踐,還是D2上克軍對YUI3分享帶來的誘惑,無不讓人感覺YUI3帶給人的感官衝擊,如今,淘寶電子雜誌、網路文學、彩票等產品已經在使用YUI3,今天,讓我們來對YUI3在淘寶彩票項目中的一些實踐做一些簡介,希望給各位同仁帶來一些參考和協助。

1,天然優良的架構

淘寶彩票是一個包含諸多彩種的產品系列,各彩種之間有相當多的可通用部分,各種數字彩的玩法極為類似,此外,同一個彩種也包含不同的玩法,這些玩法則更加近似。比如這裡是雙色球、大樂透、時時彩的三星玩法和單雙玩法的UI:

可以看到,他們選球的步驟、投注增刪改的操作、號碼的校正、附加行為(追號、跟單),以及拆單和下單的邏輯,幾乎完全一致,他們之間的區別僅僅是,選球的組合形式不同、膽拖的特例、號碼位元不同、每位號碼個數不同等等,此外玩法的投注原始演算法是永遠一致的,這樣就可以將通用邏輯進行抽離,首先針對數字彩的大類做一個演算法庫,再者對選球、投注操作、追號跟單等通用的部分做功能的封裝,形成功能庫,最後最終頁面的實現只是將這些零散的功能片段進行組裝,並著力實現玩法的各個介面。顯然,YUI3是非常適合這種層級的功能分割和模組封裝的,比如,演算法庫,功能邏輯片段和玩法實現之間的層次關係為:

處理模組層次關係正是YUI的強項,代碼示意:

YUI.addmojo({
___‘ssc’:{
______path:’ssc.js’,
______requires:["c-framework"]
___},
___‘c-framework’:{
______path:’c-framework.js’,
______requires:["c-tools"]
___},
___‘c-tools’:{
______path:’c-tools.js’
___}
});

在頁面中引入ssc(時時彩)的module-name即可:

YUI.use(‘ssc’);

此外,各種玩法和功能區之間通過統一的介面串連起來。因為YUI3的模組依賴的機制可以方便的實現高層的module覆蓋低層的module,這樣就類比了“重載”,以及“多態”。比如,每個玩法都是用單獨的module-name,每個玩法的介面格式均保持統一:

YUI.add(‘module-name’,function(Y){
___Abacus["module-name"] = {
______verify:function(){
_________//…本玩法的選號球的驗證
______},
______getNakedBets:function(){
_________//..本玩法獲得原始投注資料
______},
______getWrappedBets:function(){
_________//..本玩法獲得封裝後的投注
______}
___};
});

將此玩法根據需要應用到頁面中去:

YUI.use(‘module-name’);

這樣,在運行時就可以根據key(module-name)得到每個玩法對象,由投注操作(C.Basket)、輔助操作區(C.Donkeyman)去調用這些即時對象的介面來完成整個投注流程,而C.Basket和C.Donkeyman這些邏輯根本不需要知道他調用了誰,只需要知道他調用了“某一類東西中的一個”的方法即可。這樣的話,YUI3即為這種層級的功能分離提供了一個天然優良的架構,在後續開發大量功能類似、細節有差異的各個彩種的時候,只要重用度做的合理,二次開發是非常快速,也很方便維護。

2,最原始的解耦思想

在我學習使用YUI的過程中,體會最深的並不是YUI的實現細節是如何精妙,而是架構作者埋藏在源碼字裡行間最原生最裸露的設計模式精髓——介面。模組通訊依賴於介面,串接各個邏輯使用介面,多態的實現更要靠介面。在YUI裡,從Node的封裝到Base的構造,萬變的架構始終沒能離開這最原始的解耦方式,當架構的重心從底層轉移到應用程式層的時候,依然能強烈的感覺到介面在功能解耦方面的威力,比如,在時時彩的頁面中共有10中選號玩法,

每種玩法都具有相同的介面,在運行時,功能區域(比如C.Basket投注操作)對玩法的調用始終通過介面,而根本不用在乎調用的是誰。因為每種玩法的介面都是一樣的:

3,YUI3不止是“架構”

有人說yui3粒度太高,淘寶又沒有combo,高粒度和高效能之間難道是魚和熊掌嗎?非也,動態合并代碼是一種思路,和架構無關,和cdn無關,任何人理解動態合并代碼的原理手寫一個新的架構也不是麻煩事,還有人說yui不能合并非yui的代碼,其實只要找對地方稍微hack下yui-loader即可,這些都不是重點,重點在於YUI如何適應開發、測試、發布和bugfix的整個過程,環境太多,調試太麻煩,環境太少,很多bug測不出來,工程師和QA似乎永遠是一對矛盾,當然我們可以將線上環境原封不動拷貝到本地,做一個鏡像,完全基於本地開發,這成本實在太高,萬一一個項目開發時間很長,線上環境更新了好幾個版本,本地鏡像還是舊的,這就麻煩了,即使有svn,找log,對代碼,也夠讓人頭疼的。其實在apache寫幾個rewrite規則就可以做到即時鏡像(可以參照這裡),不管是合并代碼,還是調試源碼都很方便,不用看著一大堆的壓縮代碼思前想後的想切換到哪個環境?

時時彩的項目中,page.js既是combo後轉存下來的檔案,當然,這裡無論如何還是要做一下“另存新檔”的操作,不失為一種權宜之計。

因此,YUI3作為YAHOO前端技術的一小部分,他所帶來的開發思路的靈感要遠遠超過YUI3本身。

4,規範的力量

得益於YUI3的解耦能力,頁面功能亦可做進一步劃分,純粹的widget式的互動和功能性邏輯,比如彩票中的選號方法就是功能性邏輯,而頁面中比較邊緣的不太起眼的互動則是widget式的互動,這類widget式的互動在商務邏輯層面並無語義,僅僅是為了互動而互動,這些快捷互動的代碼就可以直接在頁面中拼裝好,完全不用將這些在業務層無語義的代碼參雜進商務邏輯的代碼中,比如:

這裡包含簡單分頁、tabview、展開摺疊、下拉式功能表等,這些快捷互動在頁面中的實現大致如下:

TBloader.require(‘slide’).onReady(function(Y){
___new Y.Slide(‘J_donkeyman_subtab’,{
______eventype:’click’
___});
});

而諸如slide、simple-page和collapse這些邏輯,則更適合做成widget,這樣到處都可以使用了。這裡則不得不提到Y.Base和Y.Widget,為開發人員開發組件搭建了一套現成的模板,其實,由此可以窺見YUI對規範的理解,規範的精髓是統一,效率和合理性是次要的,不管是簡單的分頁,還是複雜點的tabview,但對於簡單的widget,Y.Base和Y.Widget似乎有些浪費,但在規範至上的理念中,這又有什麼所謂呢,畢竟統一規格可以使得開發人員花更少的精力做出更健壯更具重用價值的組件,這也是YUI在複雜度和規範之間做出的取捨,在越複雜的項目中,這種取捨的價值越能體現出來。

5,迷惘在快餐式的前端開發中

這裡不得不提及我們越來越沒有技術含量的前端工作,相比於傳統軟體工程師,前端工程師似乎更習慣於堆代碼,表面看起來,前端開發用不著演算法,也很少用設計模式,做東西沒有概設和詳設,甚至於沒畫過流程圖,因為前端太“所見即所得 (WYSIWYG)”了,不容易看到view背後的control和data,外加上千變萬化的需求變更,前端工程師似乎總是在忙著響應五花八門的需求、堆代碼實現功能,最後的作品不是用心設計出來的,而是拼湊出來的,即便實現了功能性需求,也很難做到品質的內秀,久而久之,導致一個系統的複雜度完全超過任何人掌控的範圍,最終成為二次開發中的最大障礙,那麼,你是否也迷失在這快餐式的前端開發中呢?當你再次翻開那本破舊的“資料結構”的時候,是否會有一絲沒落?

如果你還在迷惘其中,我只想建議你多讀一讀yui的源碼,或許你會回想起一些關於演算法、設計模式、工程化、標準化所帶給你最本初的編程美的感受。

6,YUI3的缺憾

無專屬偶,YUI3太過龐大的身軀帶來更便捷的開發,也帶來一些顯而易見的缺憾,比如dom操作效能不高,學習成本太高,入門相對有難度,更不用說深入理解和熟練應用了,這似乎是YUI最致命的缺憾,相比其他架構,他的確太複雜了,當然,這和YUI所定位的使用人群有關,不過,這又有什麼所謂呢,我們不能老是停留在入門級的水平,不是嗎?



相關文章

Alibaba Cloud 10 Year Anniversary

With You, We are Shaping a Digital World, 2009-2019

Learn more >

Apsara Conference 2019

The Rise of Data Intelligence, September 25th - 27th, Hangzhou, China

Learn more >

Alibaba Cloud Free Trial

Learn and experience the power of Alibaba Cloud with a free trial worth $300-1200 USD

Learn more >

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。