讀玉伯之Sea.js、開源與前端之路
下面是CSDN訪談正文：
CSDN：先介紹一下自己和目前的工作吧！
玉伯：我叫王保平，阿里花名玉伯。目前在支付寶前端技術部工作，從事前端基礎類庫、工具等產品的研發。喜歡編碼、熱愛思考，努力把每一天過得平淡又精彩。
CSDN：Sea.js 是什麼？致力於解決什麼問題？
玉伯：Sea.js 是一個很純粹小巧的模組載入器，它只解決一個問題：前端程式碼的模組化。通過 Sea.js，可以將大量 JavaScript 程式碼封裝成一個個小模組，然後實現模組的載入和依賴管理。
有了 Sea.js，我們就可以書寫模組了。Arale 則是一套滿足支付寶需求的通用模組集合，是一套基於模組化的前端基礎類庫，目前具有近百個模組，簡單易用。
CSDN：發起 Sea.js 專案的初衷是什麼？它的本質意義是什麼？
玉伯：2008 年，在前端開發過程中，經常會出現一個單檔案幾千行甚至近萬行的情況。這種大檔案，對協作開發、後續維護、效能調優等都不利。Sea.js 初衷是幫助前端開發工程師能將大檔案拆分成小檔案，能保持小顆粒度的模組化開發，同時不需要過多考慮依賴關係，讓依賴管理輕鬆自如，讓模組化開發變得更自然，就像瀏覽器原生提供的一樣。
Sea.js 的本質意義是通過模組化開發，來提高程式碼的可維護性。對工程師而言，是關注度分離，能將更多精力聚焦在程式碼本身的邏輯上。
CSDN：Sea.js 的設計思想是什麼？是如何具體實現的？
玉伯：Sea.js 的核心設計思想是「保持簡單」。有兩層含義：
-
對外保持使用介面的簡單。Sea.js的常用API只有7個，使用者一旦瞭解，基本沒什麼記憶成本，可以快速上手。
-
內部實現程式碼儘可能簡單。追求內部實現的簡單有很多好處，比如別人可以比較容易讀懂原始碼，這樣就能參與進來協同開發。原始碼簡單，往往也意味著不太會有晦澀的 bug 存在。Sea.js 的內部實現，一直在往「簡單得明顯沒有 bug」的方向努力。
除了保持簡單，Sea.js 的設計理念裡還有職責清晰、效能優先和適度完備。
職責清晰是讓 Sea.js 的範疇明確，隨時知道自己應該做什麼，不應該做什麼。一個框架，最怕的是需求膨脹，最怕的是複雜化。
效能優先是因為 Sea.js 是底層載入器，倘若效能不好，直接會影響頁面效能，因此原始碼中有不少地方會刻意追求效能。
適度完備是從功能的層面看 Sea.js 的 API 是否能滿足常用需求，同時又能通過外掛機制對外提供適度的可擴充套件性。Sea.js 不追求能夠滿足所有需求，而是追求 2/8 原則。
具體程式碼實現純文字不太好描述，感興趣的可以閱讀原始碼：https://github.com/seajs/seajs，所有原始碼都在上面，歡迎閱讀，歡迎給出建議。
CSDN：Sea.js 開發過程中，最大的困難是什麼？是如何解決的？
玉伯：這個說起來比較有意思，在開發過程中，Sea.js 最大的困難，不是編碼，而是模組定義規範的確定。
在業界，目前流行的模組定義規範，有 CommonJS 的 Modues/1.x 規範，還有RequireJS 社群倡導的非同步模組定義規範 AMD。這兩個規範，在社群裡存在比較大的討論，各有利弊，適用於不同的執行環境。Sea.js 最後採用的是延自 CommonJS Modules/2.0 規範的通用模組定義規範 CMD。這些規範的優劣，至今都有爭議。不同的團隊，不同的場景下，喜好和選擇都有可能不同。
隨著 Sea.js 的推廣，CMD 規範目前在國內已經有相當多人認可。接下來會進一步國際化，希望能得到更大社群範圍內的認可。這條路還很長，不能說已解決了，一切還在解決的路上。
不過，這些都不是關鍵。即便 Sea.js 以後死掉，只要大家對模組化開發理念有深度認可，那一切也就值了。
CSDN：Sea.js 和 Arale 目前分別應用在哪些地方？
玉伯：Sea.js 目前已應用在阿里、騰訊、網易等很多公司，具體可以檢視 seajs.org 首頁下面的 logo 牆。國內有大量中小網站採用 Sea.js 開發。
Arale 的使用範圍是支付寶，還有阿里巴巴 ICBU 部門，在一小部分國內創業型公司中也有使用。
CSDN：您之前還開發過前端類庫 KISSY，而 Arale 也是一個基於 Sea.js 的前端類庫，兩者有什麼不同？這是在「造輪子」嗎？它們的開發初衷是什麼？目標又是什麼？
玉伯：KISSY 和 Arale 都是前端基礎類庫，從元件提供的功能來講，存在很大重合度。但從理念上來講，這兩個類庫有比較大的不同。
KISSY 是大教堂式思路，所有元件，從底層基礎元件，到上層 UI 元件等等，都是自主研發。這和業界的 YUI3、Sencha 等類庫的思路是一樣的。
Arale 有所不同。Arale 的首要理念是「開放」。開放不光意味著將自己做好的元件貢獻給社群，開放更意味著將社群已有的優秀元件直接拿進來用。在開放的理念下，Arale 類庫裡，直接引入了 jQuery、Backbone、Moment、Handlebars 等業界元件。在這種思路下，Arale 能與開源社群緊密互動，彼此快速共進。
KISSY 和 Arale 的初衷都很簡單，KISSY 是解決淘寶的前端基礎類庫問題，Arale 則是解決支付寶的前端基礎類庫問題。兩者的目標，都是減少前端開發過程中的重複工作量，儘量提高前端開發的工作效率，同時在通用元件層面保障全站的使用者體驗。
CSDN：Sea.js 和 Arale 未來會如何發展？目標是什麼？
玉伯：從 2.0 版本開始，Sea.js 的發展目標是做簡單、純粹的模組載入器。甚至希望從 2.x 的某個版本開始，就不需要更新了，就能滿足絕大部分需求，能非常穩定下來，不需要再升級。
Sea.js 穩定後，更多精力會放在 Arale 等前端基礎類庫的建設上。Sea.js 名稱中的 Sea，是「海納百川、有容乃大」的意思。Sea.js 希望是一片海，可以容納各種各樣的模組，希望能形成一個模組的生態圈，能形成生態鏈，能促進良性迴圈，能讓整個前端開發界都受益。
開源的點滴感悟
CSDN：為什麼選擇將這些專案開源出來？開源對於自己的技能提升是否有幫助？
玉伯：選擇開源有兩個初衷：
- 將好的東西貢獻給社群；
- 通過社群讓東西更好。
Sea.js 是在開源中不斷成長流行的，很多需求點、優化點，如果不是開源，Sea.js 很難走到今天。
開源本身對技能提升個人覺得是有限的，但技能之外的軟技能提升，比如溝通協作、產品化思路、運營管理等非常有幫助。通過開源的方式，比較容易讓一個技術人員有產品觀，能讓自己的眼界在編碼之外看到更多美景。
CSDN：在開源領域這麼久，您有什麼感悟？您理解的「開源精神」是什麼？
玉伯：我理解的開源精神，有三點：
-
拿來主義。懂得從現有成熟開源專案中去挑選符合自己需求的專案，直接拿來用。程式設計師容易犯一個病，就是什麼東西都想自己造，或者對別人造的，淺嘗輒止就判斷別人的不行。真正的拿來主義，需要一顆謙卑的心。在「拿」的過程中，需要去看文件，甚至去讀原始碼，這些過程，對程式設計師的技能增長都非常有幫助。很多程式設計師的技能提升，並非是寫的程式碼太少，而是看的程式碼不夠多。懂得去看、去理解、去用，是邁入開源世界的第一步。
-
參與比主導更重要。開源世界裡永遠不會有完美的專案。當你學會了「拿來主義」後，在使用開源專案時，肯定會遇到各種bug、各種特性不滿足。這時，你可以自己去新開一個專案，也可以參與到該開源專案中去，幫助作者一起來完善。個人覺得對於絕大部分專案來說，參與進去幫助完善是更明智的選擇。參與進去，可以讓你更懂得美，懂得感恩之心，懂得回饋之情。這在過程中，你的功力，往往也會大增。不光是技術上的進步，還包括英語讀寫能力。在人性溝通上，你也會收穫很多，這是無價的財富。
-
重視社群。除了程式碼，還有文件、測試用例、Issues 管理、版本釋出、升級策略、書籍、視訊等等。jQuery、Backbone、AngularJS 等成熟專案，成熟的是社群，而不是原始碼。好的社群，是在 Google 中一搜索，就能找到不少資料。好的社群，是你踩過的坑，經常已經有人也踩過並整理分享出來了。社群的形成非常不易，如果選擇了開源，從專案一開始，就儘量可能的去讓社群逐步形成起來。社群形成後，開源才會活起來，否則就是死開源。
最後，知易行難。上面的道理或許大家都懂，真要做到，則是一場修行。Sea.js 和 Arale 也才剛剛上路。好在，選擇了，就不怕遠。
CSDN：您認為，KISSY、Seajs 和 Arale 這些開源專案為什麼能取得成功？它們是否從社群中獲得了貢獻？
玉伯：還談不上成功。目前社群未成型，以 Sea.js 和 Arale 為例，目前從社群中獲得的貢獻有：
-
bugs 反饋和新功能討論。這很重要，只滿足一個公司的需求時，很多想法都想不到，當有多個公司使用你的產品時，在某些點上可以幫團隊開啟思路，去看到不少原來看不到的地方，甚至有時會有「為什麼我們之前沒想到」的感慨。
-
全網測試。這一塊，在Sea.js的開發上尤為明顯。Sea.js在每次釋出前，都會邀請社群人員一起幫忙執行測試用例。前端開發與後端開發的最大區別之一，就是後端程式碼的執行環境是固定的，是開發人員自己選擇的，而前端程式碼的執行環境卻無法固定，是使用者決定的。這使得前端程式碼的測試，除了自己的內部測試，還需要線上的“眾包測試”。開源使得“眾包”成為可能。
-
程式碼優化。由於是開源的，程式碼是公開的，偶爾就會有人會去閱讀原始碼，並發現其中可以優化的一些點。這在Sea.js和Arale裡都有一些案例，有時挺感動的。社群的力量，會給人驚喜。
CSDN：您如何看待國內的開源環境？
玉伯：國內開源環境還不夠理想，但越來越好了。很期待更多的公司加入並推動開源活動。對於前端開發領域，一定程度上真沒有什麼祕密，期待更多公司的開放。
前端泛談
CSDN：前、後端開發有沒有明確的分界（是否能完全獨立）？您心目中理想的前、後端開發模式是什麼？
玉伯：前後端開發很難完全獨立，個人覺得也沒有必要彼此獨立。我的想法是「全端工程師」，都是Web 開發工程師，從前到後應該都能做才行，這對效率、質量都有好處。
但獨立的前後端開發工程師也應該存在。前端一些深鑽領域，需要前端領域專家的持續投入，後端也一樣。這些專家來自一線開發工程師，同時在某個領域有獨到的想法和執行力，能沉澱下來形成工具、技術平臺，這些平臺反過來提供給「全端工程師」去用，這是往深裡鑽的技術工具化、平臺化思路。
CSDN：有人認為，過多使用框架會導致開發者忽視對 JavaScript 原生語言特性的學習，變得懶惰，或者基礎會很薄弱；也有人認為，只要精通原生 JavaScript 就可以，無需使用框架也能開發出應用，對此您怎麼看？
玉伯：在前端開發工作中，JavaScript 語言的使用只佔比較小的一部分。更多的精力，需要花在語言之外。掌握 JavaScript 語言的基本使用，就如我們在學校學習，需要掌握中學數學的內容一樣。這一塊我覺得不難，只要肯花時間去學就好。
值得提醒的是，如果只精通原生 JavaScript，那麼就如只會中學數學一樣，雖然已經能解決很多問題，但要優雅地、更簡單地解決複雜些的問題就難了。
框架可以讓你從重複低階工作中脫離出來，特別是應用複雜到一定程度時，如果沒有框架層的抽象，程式碼往往會複雜得難以維護。在前端開發越來越複雜的今天，框架已經必不可少。學會去用、去擁抱，往往可以事半功倍。
框架不會讓你偷懶，更不會讓你基礎薄弱。即便是 jQuery，如果你對 DOM 的基本原生操作不太會，那麼你也很難真正把 jQuery 使用得很好。就如中學數學都不理解的話，要把大學數學用得很好只會是夢。
CSDN：對於繁多的前端框架，應該如何選擇？
玉伯：這個問題太大了。虛的回答是，根據自己公司的需求去選擇合適的就好。實的回答是，如果你還未找到合適的，可以嘗試去用用 Sea.js 吧，然後模仿 Arale 去沉澱一套適合公司業務的模組集合，去在業務的基礎上構建框架。
CSDN：阿里的前端開發流程是什麼樣的？
玉伯：不同團隊不一樣。比如淘系團隊和支付寶系團隊很多流程就不一樣。流程很大程度上取決於業務型別。淘系很多業務是導購型別，快速往往是第一要素，支付寶很多業務則是金融型別的，穩定與安全往往是第一位的。這兩種要求下，產生的流程有很不一樣，甚至可以說是地球的兩極。目前也在逐步靠攏，尋求合理權衡下的統一。
CSDN：能否分享一些您的學習經歷、經驗？您認為學習前端開發最重要的是什麼？
玉伯：前端開發是距離使用者最近的編碼工作。個人覺得，一個優秀的前端開發工程師，一定要對產品有愛。如果做的產品自己都不怎麼用，那麼你對很多互動細節很可能會缺乏深思，你會在潛意識裡忽略掉。但是，如果你自己也用這個產品，那麼你就不僅僅是在編碼了，你同時還是 PD、PM、測試等等角色，甚至你就是這個產品的 CEO。當 CEO 的感覺挺累但挺爽。去找到你認可、讓你為之瘋狂的產品吧，你的開發能力會在你的瘋狂中突飛猛進。
CSDN：您眼中的技術大牛是什麼樣的？如何成為技術大牛？
玉伯：我理解的技術大牛，是把事情做得很專業的人。溫伯格在《理解專業程式設計師》中對專業有很好的定義：
專業是，具有了不起的技藝或經驗。
併為其他人解決問題，無論問題有多麻煩。
很多人在追求具有了不起的技藝或經驗，但只有這一項，永遠稱不上「專業」。專業還必須不厭其煩地為他人解決問題。無論做業務還是基礎技術，都能做得很專業。追求專業、變得專業，價值、成就感往往就會水到渠成。成為技術大牛，也就是自然而然的成長。
總結：看完此篇文章後，受益良多，一直關注玉伯的微博，今天才知道真名，囧！最近也在嘗試使用seajs，也研究原始碼，從中學到不少東西。so，無論在哪，在何行業，在何領域，都要有一顆上進的心、幫助他人之心、感恩之心。正如玉伯所說，“很期待更多的公司加入並推動開源活動。對於前端開發領域，一定程度上真沒有什麼祕密，期待更多公司的開放。”，供菜鳥研究、學習。最後預祝中國的前端技術在各位大牛的引領下，向前、向前、再向前！
附：一些國內大型網際網路公司的前端框架：