個人架構經驗系列文章 - 前端架構

框架層面：近幾年前端發展很快，前端之因此叫前端由於前端是已經能夠獨立成爲一種職業了，js也再也不是十年前的玩具了，之前富客戶端RIA的應用可能會用flash/flex或是silverlight，如今可使用js來完成大部分的功能，所以js做爲一門前端的支撐語言也不只僅是進行的簡單的編碼，愈來愈多框架性的東西出現了。愈來愈多的開發模式轉變爲後端只是吐json的數據源，而前端作全部UI的事情。

　　MVC

　　MVC實現職責分離是很好的，大多數網站在後端都會引入MVC框架，對於一個前端負責全部呈現和前端業務邏輯的網站來講，使用MVC框架也是頗有好處的。Javascript的MVC框架如今不少。每個框架其實都有其特色的，可是前端的MVC框架會和後端的有些不一樣的。好比前端的MVC框架可能會作一些M和V元素的雙向綁定，對於後端來講每每是單向的比較多。經過引入MVC框架咱們可讓同一個頁面作不少事情，經過一個不刷新的頁面實現一個應用程序的根基，還能夠很清晰地進行MVC的分離而且突出M的概念，這是沒有框架所辦不到的。

　　通信

　　對於一個比較複雜的頁面可能會有比較多的Javascript模塊，若是要進行模塊之間通信的話(好比一個頁面有左邊菜單和導航以及列表，左邊菜單點選一級分類以後要通知導航加上去這項，而且通知列表從新讀取數據並刷新，而後從導航刪除這個選擇的話要通知列表從新獲取數據，通知菜單顯示全部)。對於比較複雜的通信，若是把模塊模塊之間進行強耦合直接調用其它模塊的函數的話是不利於可維護性的，我以爲能夠引入發佈訂閱機制，每個模塊作了什麼修改把信息發佈出去，關心這個信息的人訂閱這個信息，而且在回調函數裏面作相應的操做就能夠了。可使用Amplifyjs做爲發佈訂閱的框架。

　　模板

　　對於前端來講和後端同樣一個比較麻煩的問題就是每每會在腳本里面把html也混在一塊兒，我的以爲是這樣的，若是對於很是瑣碎一些dom修改問題倒不大，若是是大塊的html拼接的話，數據和html甚至是css混合在一塊兒，那麼代碼的可維護程度很是差。此時能夠考慮使用一些模板引擎來分離數據和表現，好比Twitter hoganjs。因爲不少模板引擎，好比大鬍子引擎不只僅是針對前端的，後端語言也有相應的引擎，所以甚至能夠把模板放在文本文件中，前端後端共同使用一套模板引擎，也就是說如今的代碼偏向於服務端渲染的那麼就在後端使用模板，若是要之後改成客戶端渲染了這套模板能夠直接被前端使用。 資源示例

　　類庫

　　除了框架以外還有不少類庫，好比jquery，underscore，linq.js(linq to javascript)，jscex(wind)反正後端有啥如今前端也有啥，盡情發揮想象吧。用好這些框架能夠大大改善生產力的，腳本能作的事情真的比想象的要多的多。我是作後端的前端知道的很少在這裏列出的可能只是九牛一毛。

　　依賴

　　可使用Requirejs、Commonjs之類的組件來管理腳本之間的依賴，好處不少的，咱們的模塊只須要寫清楚須要依賴什麼，Requirejs天然會幫咱們按照必定的次序加載進來，這樣咱們既不用擔憂順序問題也不用擔憂組件的版本號問題。基於Requirejs它具備豐富的配置，即便是咱們進行了靜態資源合併也徹底能處理，只要經過配置把組件配置到相同的服務端生成的一個路徑上便可，不過之前在作的時候發現它會自動加上.js 擴展名，不過徹底能夠經過改Requirejs源代碼解決。在架構上個人觀點是既然使用開源的東西，遇到問題了就不要去怕改源代碼。咱們必定不能停留在框架的使用者，定製框架甚至向做者貢獻本身的代碼沒有這麼難。 設計層面：

　　職責分離的理念

　　雖然咱們都知道CSS樣式、JS行爲以及HTML結構。我的以爲只有HTML是必須的，也就是說若是一個頁面沒有樣式沒有腳本的話它應該是一個清晰的頁面，能夠大體表現出頁面須要表現的內容，只不過樣子比較難看，而且也是交互的。若是說不少功能是ajax實現的話那麼就把交互工做轉到服務端實現服務端的渲染。多了樣式只是佈局上樣子上更好看，多了腳本只是交互性上更友好，不須要刷新頁面，可是少了也不表明這個網站就是廢物了，如今有不少理念其實目的是同樣的。若是達不到這個境界至少咱們要很明確的讓css、js和html履行本身的職責，不要把過多的事情賦予不相關的組件。好比儘可能不要在html中包含操做性的腳本代碼，而是應該直接在腳本中選擇dom元素進行操做，儘可能不要在腳本中包含大段的html代碼而是應該從模板讀取而後把數據填充進去，也儘可能不要在html代碼中包含大量內嵌的樣式而是應該經過選擇器選擇進行樣式賦值。 資源示例

　　分層和目錄結構

　　對於一個比較複雜的大型的項目，合理規劃目錄結構也是很重要的，你可能會說腳本和樣式分兩個目錄就能夠了，可是若是一個複雜的項目有幾百個腳本都列在一個文件夾下嗎?後端有分層的概念其實前端徹底也能夠有分層的概念，有表現層、業務邏輯層和模型層，而後是下面的數據訪問ajax層，固然還會有常量的文件，我反問以爲前端的分層能夠超大型項目的ios或android程序來靠。好比以前我作的一個ios程序的示例,我的以爲這樣的分層就比較一目瞭然的。

　　合併和拆分的平衡

　　不少時候架構上的東西就是一種權衡，若是有固定的標準的話也就不須要架構師了，咱們只須要按照固定的標準去作就好了。好比，一個頁面上使用了10個腳本文件，5個樣式文件，按道理說合併成兩個文件能夠達到最小的請求數，但這樣必定是好的嗎?這個10個腳本和5個樣式文件中有不少或許是其它頁面也須要公用的，若是僅僅簡單的合併在一塊兒反而可能增長用戶的下載流量，所以怎麼規劃通用的東西合成一個文件，框架的文件單獨，而每個頁面都有本身獨特的腳本和樣式，也是一種學問。 性能層面：

　　性能檢測

　　諸如YSlow和PageSpeed等工具能夠分析出前端的性能問題，在這裏就不展開討論了。對於前端來講因爲涉及到用戶的客戶端環境和網絡環境因此狀況不是這麼單純，可是咱們能夠作到的就是在咱們的可控範圍以內儘可能減小用戶域名解析數量，減小用戶下載的數據量，增長併發等等。其實說白了，咱們就是清理管道使得管道更大，或者增長更多的管道，或者就是儘可能讓管道以內的水少一點了，這樣就能夠更順暢。 資源示例

　　性能分析

　　如今有一些工具能夠對Javascript的性能甚至是DOM解析的狀況進行細緻的分析，好比dynaTrace AJAX Edition，經過這樣的工具咱們能夠分析咱們的腳本代碼以及頁面佈局是否合理，從開發的角度來全面瞭解和優化咱們的前端代碼。客戶端的資源雖然不像服務端的資源這麼重要，可是爲了給用戶的機制體驗最好仍是對客戶端的性能消耗有所優化。