太極生兩儀，兩儀生四象。

    公司整個前端體系不太完善，很難保證效率和質量。 彼此缺少溝通，致使重複勞動。相同的東西被寫過不少遍，不能發揮集體智慧。誠然在這種模式下就算我的作的再好，也沒法提高總體的效率。除非每一個人都意識到而且按照必定的標準去執行，纔會往更加良性的方向發展。如下是我基於對目前的前端體系所設計的總體架構，具體功能均爲實現，只是提供一個實現思路。固然有時間我會一個個實現的。

朱雀：性能日誌 + 錯誤日誌

背景：

項目開發完成後，沒有一個完善的日誌系統，咱們很難了解到發佈出去的代碼在用戶機器上執行是否正確，因此須要創建前端代碼性能相關的監控系統。100用戶出現問題，可能只有10個會向咱們反饋，而剩下的會對咱們好感度下降，極可能直接不用。 並且就算這10個用戶，也須要咱們花費很久去了解一些信息，譬如瀏覽器版本，重現過程什麼的，頗爲繁瑣

 

設計思路：

設計一種獨立的系統，該系統做爲中間服務器存在，與具體項目解耦。 也就是說任何想用我服務的，只須要前端加上幾行代碼，就能夠實現日誌上傳。須要查看信息的時候，只要登陸個人平臺(盤古：http://pangu.rd.800best.com/dashboard),而後點擊朱雀-前端日誌收集平臺，就能夠看到本身所屬項目的詳細收集信息（如下操做相似，不贅述）。

實現：

要實現這一功能。

第一要搭建一個後端服務器，這裏考慮直接使用express亦或koa。用於接收http請求並持久化。

第二要製做一個管理界面。 界面能夠根據類型（性能日誌，錯誤日誌），時間，帳號，瀏覽器等篩選

使用方式：

const PERFORMANCE_URL = "http://zhuque.800best.com/performance/post"; 

const CRASH_URL = "http://zhuque.800best.com/error/error/post"; 

const data = {

msg: errorMessage,

url: errorUrl,

userAgent: userAgent,

time: new Date()

}

fetch.post({

    URL: CRASH_URL ,

    data: data

})

const perf = (window.webkitPerformance ? window.webkitPerformance : window.msPerformance ),

   const timing = pref.timing;

   perf = perf  ? perf : window.performance;

   if( perf  && timing ) {


   let perfData = {};

   for (let key in timing) {
     if (Object.prototype.hasOwnProperty.call(timing, key)) {
         perfData.[key] = (timing[key] - navigationStart) ;
      }
    }

fetch.post({

    URL: PERFORMANCE_URL ,

    data: perfData

})

}

若是把這個代碼進一步改進，能夠變成這樣的：

import bestLog from 'bestLog';
// bestLog 構造函數，接受兩個參數一個是PERFORMANCE_URL 另外一個是CRASH_URL 
// 不指定會使用默認的，指定會覆蓋，而後請求會發到指定的url
function init() {
  bestLog({
    PERFORMANCE_URL: 'bestsmart.800best.com'
});
}
// 這樣瀏覽器只要掛了，而且error 沒有被catch  就會觸發window.onerror事件，進一步執行個人代碼

玄武：直出中間件（ssr + prefetch + prerender）

背景：

360海淘目前嘗試使用了服務端渲染，還開了一個關於服務端渲染的技術分享， 這種精神和活動確實值得發揚。 可是如今的結果依然不是很理想，其餘項目組須要使用服務端渲染依然要從新開始填坑。另外具體實現和業務鑲嵌比較深刻，移植相對困難。 基於此，一種基於服務端渲染和資源預加載的中間件呼之欲出。  若是我須要使用服務端渲染，直接稍加修改便可。

設計思路：

任何項目組若是須要用到服務端渲染，直接接入，稍微修改代碼，就能夠享受服務端渲染帶來的直出體驗。

實現：

一：搭建中間服務器

二：服務端監聽請求，收到請求，根據項目名找到對應的路由信息。

三：根據路由信息，生成html，將html 和 state一同返回前端。

使用方法：

因爲服務端渲染的特殊性，因此須要配置沒那麼簡單。

主要有兩點 1： 事件掛載 => 服務端的生命週期只走到componentWillMount，而客戶端則會有完整的生命週期，所以部份事件能夠挪到componentDidMount中處理

                   2： 自定義構建配置： 不構建css等

蒼龍：組件平臺   

這裏能夠查看其它項目組的組件庫，能夠編輯本身組件庫。

參考：http://my.oschina.net/wanjubang/blog/673683#OSC_h2_3

白虎：自動化集成平臺

背景：

參考：http://my.oschina.net/wanjubang/blog/683635#OSC_h2_3

設計思路：

項目成員每次提交代碼都會在平臺跑一遍測試。 若是不須要執行 --disable 。 而後能夠登陸到白虎平臺查看代碼覆蓋率和 測試是否經過等信息。 項目成員只須要編寫測試用例就能夠了。管理員能夠用來查看項目的代碼質量。

實現：

系統採用典型的master/slave架構。 採用doker容器進行部署。 項目須要使用直接安裝client端，而後鏈接咱們的白虎服務器就能夠了。

使用方法：

客戶端:

reliable server -m <reliable-master:port> --verbose

伏虎: 文檔服務器 （集成mock）

參考：http://my.oschina.net/wanjubang/blog/673683#OSC_h2_1