百姓網的前端架構是怎樣的？

其實我們的前端架構還遠未成熟，可以說正在傳統前端架構到現代前端架構的轉變中，這個轉變以引入構建系統為標誌（雖然之前mobile版已經引入了stylus），從去年（2014）年初開始， 預計可能持續2到3年時間達到一個我心目中理想的較穩定架構。

之所以預期如此長的時間，是因為總體上，對於前端構建、模組化、元件方案等非常基礎和牽一發動全身的設施，我採取寧缺毋濫，看不清楚就先不上的保守策略——是不是看上去似乎和我在社區老是講新技術的形象不太相符？ ^_^

這種策略有三個原因。

第一是百姓網的性質是以資訊流為主、面向所有線民的、平臺級的互聯網服務。 凡此種性質的網站，技術選型的策略總是偏向保守的。 相對來說，以體驗為主、面向相對小眾群體、限定于特定領域的應用，可以更快的採用新技術。 像我們的內部系統就會更多採用新技術。

第二，也是更本質的原因是，架構不是光決定用個什麼系統就行的，而是牽涉方法論、工具、流程乃至組織結構等諸多層面，是需要整個團隊共同理解、實施、維護和不斷改進的。 團隊前進，架構前進。 這需要耐心。

第三，百姓網的前端團隊在建立之後很長時間裡包括我只有3個人，主要精力都在業務上。 （當然我們許多後端工程師甚至PM都附帶前端開發技能——別以為我在講段子以下絕壁是真的之我們的CEO三年前就自己玩Meteor並去矽谷見投資人時順便去參加nodejs的workshop還帶著財務總監& 我們財務總監當場只完成了helloworld表示不服回來後買了犀牛書問我學JS是不是看這本就好之看你們以後誰敢在我面前自稱技術型公司。 ）期間雖然有嘗試改變主站的一些開發方式，但是因為各種原因而無疾而終。 去年我們的前端工程師終於超過了10個人，不過和快速增長的業務相比還是遠遠不夠。 因此雖然從去年第二季度開始成立了前端架構組，但我並不急於引入各種新設施， 因為我認為對於我們這樣規模的團隊，資源的冗余度是很低的，走彎路的代價比較高。 我要確保每項引入的設施都是正確的。 （BAT這樣規模的公司就好一些，可以有多個團隊同時實施幾種不同架構方案。 我就指著他們幫我們這些中小型公司探路了，所以我見到他們的人就鼓吹他們快上新技術，呵呵。 ）

無論如何，今年會有幾項重要的前端架構的實施，比如我預期今年要上ES6！ 大家可以注意到我去年12月的C4（HTTP://weibo.com/1960954893/BBKpY8uq3）和今年1月的FEDAY上講的內容（hax/es6-in-action · GitHub）就是ES6。 這回是要玩真的哦。 總之，希望能穩健的前進，到明年這個時候再來看吧。

針對具體問題回答如下：

Q: 百姓網是否使用了 sass / stylus / less 這類預處理工具 ？

A: 百姓網mobile版用了stylus。 最新一版重構是基於 @CSS魔法 開發和維護的CMUI/CMUI · GitHub。 桌上出版因為開發歷史比較悠久，一直沒有引入預處理工具，短期也不會改。 但長期來說最終應該會引入的。

Q: 百姓網 js 模組化開發是如何組織的，是否使用了什麼模組化工具、框架？

A: 與大家預期可能不一樣，這塊我們仍然停留在刀耕火種階段。 百姓網歷史上，頁面中腳本一直用得不多，雖然很早以前 @sofish 就考慮過引入如seajs的可能性，但是實踐上，粗放的腳本合併和一個簡陋的按需載入（HTTP://s.baixing.net/js/global/defer.js）也就夠用了。 不過隨著開發規模的增長，當然早晚是要走向更成熟的模組化方案。 所以去年年初就開始評估和試驗各種方案，比如新開發的某些獨立性較高的功能元件是基於commonjs+browserify的。 總體上，因為我預期所有模組化方案最終要統一到ES6的module/loader上去，所以基本上想直接上基於遵循ES6語義和API的loader的方案。 但是ES6的module部分定案和實現比預期的慢，loader規範也被postpone到獨立spec中。 估計今年第二季度之後會引入模組化方案。 需要注意的是，模組化主要是為提升代碼的可維護性，側重開發階段。 而側重部署的模組載入或一般化的資源載入相關領域其實還有大量的可能性要探索，僅制定中的標準草案就有HTML Imports、ServiceWorker、Packaging on the Web、HTTP2等， 我們需要在架構上厘清這些不同的元件是如何協作並構成整個體系的，這對於未來Web網站和應用的整體性能提升會有極大價值，也是個長期任務。

Q: 具有完整的 html css js 代碼片段的 component，是如何 include 到各個頁面裡的，include 時對 html css js 分別進行了哪些處理？ 如果這其中的 js 又依賴于某更基礎的 js 模組，這個依賴是如何處理的？

A: 和上一個問題類似，由於歷史上百姓網的結構比較簡單，所以一直沒有引入任何一種確定的元件方案。 除了需求不是特別大之外，相比模組系統已經明確會統一到ES6，元件系統目前仍是完全不明朗的情況。 從維護角度說，模組系統其實轉換成本並不太高，元件系統就複雜多了，要從某種 元件系統切換到另一個元件系統聽上去就很恐怖。 此外，目前業界流行的MV*元件框架絕大多數是純瀏覽器端方案，在百姓網主站這樣以資訊流為主、SEO必需、有較高瀏覽器相容性要求的網站來說，無法直接使用。 目前業界缺乏能很好的統一瀏覽器端和伺服器端的方案，這是類似百姓網這樣的中大型互聯網網站少有直接引入類似MV*元件框架的原因。 儘管目前沒有確定的計畫，但在內部系統和不涉及主站的新專案中會鼓勵團隊成員嘗試新技術和方案，目前有少數內部專案已經嘗試了Angular。 大型Web應用中，元件化的需求是不可避免的（如 block 和 include 協作問題 · Issue #38 · baixing/jedi · GitHub），只是最終的答案可能要再過一段時間才會浮現出來。

Q: 開發環境的代碼在發佈上線過程中做了哪些處理？

A: 我們有一套PHP寫的deploy系統，前端資源的編譯、壓縮、版本化、替換路徑等步驟都是該系統執行的。 從去年年初開始我們引入了gulp來進行mobile版的前端構建，會逐步將前述步驟移回到gulp工具鏈中，並增加更多的處理，比如圖片優化和模組打包。 desktop版今年應該也會引入。

Q: nodejs 在百姓網技術棧中承擔了哪些任務？

A: 前端構建階段的整條工具鏈是完全基於nodejs平臺，這個自不用說。 線上上服務中，部分日誌系統是基於nodejs，並且計畫會進一步將更多涉及前端的日誌系統移轉至nodejs。 另外我們使用的協力廠商服務如LeanCloud的消息服務估計是基於nodejs平臺的（雖然與我們無關，但是因為這個服務我們是首先吃螃蟹的使用者，它本還沒有js sdk，我只好親自搞了一個hax/avos-chat · GitHub，所以順便說說）。 我們的後端是基於PHP的，但我們並不排斥其他平臺，如我們的新業務線也有採用基於python的系統。 內部系統也有許多基於nodejs平臺，並可能採用新的app框架如Koa。 主站系統部分（特別是表現層）遷移到nodejs平臺從架構層面來說也一直是可選項。 目前的障礙更多的是在較缺乏有nodejs運維經驗的工程師，有興趣的同學歡迎投遞簡歷。

以上。