前端如何高效的與后端協作開發
1.前后端分離
前端與后端的分離，能使前端的開發脫離后端的開發模式，擁有更大的自由度，以此便可做前端工程化、組件化、單頁面應用等。
2. 盡量避免后端模板渲染
web 應用的渲染方式分為服務器端渲染和客戶端渲染，當下比較推薦的方式是客戶端渲染，數據使用全 ajax 的方式進行交互。
除非在一些不得不使用服務器端渲染的情況下(如門戶、電商等)，應當盡量使用客戶端渲染，因為客戶端渲染更能使前后端分離(項目分離、代碼解耦、協作分離、職責分離等)，也能更好的做本地接口模擬開發，提升開發效率。
即使用服務器端渲染，在技術支持的條件下，可以使用 node 中間層(由前端人員開發)，代替傳統的后端模板渲染，這樣可以使后端與前端完全解耦，后端與前端只有數據上的往來。
3. 盡量避免大量的線上調試
做好本地接口模擬開發(包括后端模板渲染)，避免大量的線上調試，因為線上調試很不方便，也很費事，并且每次更新代碼，都需要重新構建，然后同步到服務器。
所以做好本地接口模擬開發，只要程序在本地運行是沒問題的，一般線上就不會有太大的問題，這樣就能大幅降低調試工作量，提升開發效率。
4. 本地接口模擬開發
本地接口模擬就是在本地模擬一個與服務器差不多的環境，能夠提供數據所需的接口，進行錯誤模擬處理等等。
本地接口模擬開發的意義就在于能夠在本地完成幾乎所有的開發與調試，盡量減少線上的調試，提高開發效率。
一些常用庫：
- browser-sync(https://github.com/BrowserSync/browser-sync)：能讓瀏覽器實時、快速響應文件更改( html、 js、css、 sass、 less 等)并自動刷新頁面，并且可以同時在PC、平板、手機等設備下進行調試。
- webpack-dev-middleware(https://github.com/webpack/webpack-dev-middleware)：A development middleware for webpack。
- webpack-hot-middleware
- (https://github.com/webpack-contrib/webpack-hot-middleware)：熱更新本地開發瀏覽器服務。
另外，本地接口模擬開發需要后端開發人員有規范的接口文檔。
5. 規范的接口文檔
前端與后端協作提升開發效率的一個很重要的方法就是減少溝通：能夠形成紙質的文檔就不要口頭溝通、能夠把接口文檔寫清楚也不要口頭溝通(參數、數據結構、字段含義等)，特別是線上協作的時候，面對面交流是很困難的。
一個良好的接口文檔應當有以下的幾點要求與信息：
- 格式簡潔清晰：推薦用 API Blueprint(https://apiblueprint.org/)
- 分組：當接口很多的時候，分組就很必要了
- 接口名、接口描述、接口地址
- http 方法、參數、headers、是否序列化
- http 狀態碼、響應數據
接口文檔可以用一些文檔服務(如 leanote(https://github.com/leanote/leanote))來管理文檔，也可以用 git 來管理;書寫方式可以用 markdown，也可以 YAML、 JSON 等。
推薦使用 markdown 方式寫文檔，用 git 管理文檔。
可以參考：
- 本地化接口模擬、前后端并行開發(https://segmentfault.com/a/1190000015297352)
- API Blueprint(https://apiblueprint.org/)
6. 去緩存
前端需要做好去客戶端緩存的功能，保證用戶始終都是使用的***資源，不會因為因為緩存的問題而出現 bug。
傳統的去緩存是在靜態資源 url 上加上版本號或者時間戳，不過因為構建工具的出現以及一些瀏覽器已經不支持這種方式了的緣故，這種方式已經是過去時了。
現在去緩存是將文件 hash 化命名，只要文件變動，文件名就會不一樣，以此才能徹底的去緩存。如果使用 webpack 進行打包，會自動將所有文件進行 hash 化命名。
7. 做好錯誤處理
前端與后端都需要各自做好錯誤處理，以便發生錯誤能夠有友好的提示，也能在用戶反饋時快速準確定位錯誤來源和原因。
一般前端的錯誤分為：
- 腳本運行錯誤： js 腳本錯誤，找到堆棧信息，然后解決
- 接口錯誤：服務器報錯、數據返回不對、沒有響應數據、超時等
而接口錯誤分為：
- 狀態碼錯誤(狀態碼非 2XX)：服務器報錯、超時等
- 數據錯誤：沒有響應數據、數據格式不對、數據內容不對
8. 運行時捕捉 js 腳本錯誤
當用戶在用線上的程序時，怎么知道有沒有出 bug;如果出 bug 了，報的是什么錯;如果是 js 報錯，怎么知道是那一行運行出了錯?
所以，在程序運行時捕捉 js 腳本錯誤，并上報到服務器，是非常有必要的。
這里就要用到 window.onerror 了：
- window.onerror =(errorMessage,scriptURI, lineNumber,columnNumber, errorObj)=>{
- const data ={
- title:document . getElementsByTagName ( 'title' )[ 0 ]. innerText ,
- errorMessage ,
- scriptURI ,
- lineNumber ,
- columnNumber ,
- detailMessage : ( errorObj &&errorObj . message ) || '' ,
- stack : (errorObj && errorObj . stack )|| '' ,
- userAgent :window . navigator . userAgent ,
- locationHref : window . location . href ,
- cookie: window . document . cookie ,
- };
- post ( 'url' , data );
- // 上報到服務器
- };
線上的 js 腳本都是壓縮過的，需要用 sourcemap 文件與 source-map(https://github.com/mozilla/source-map) 查看原始的報錯堆棧信息。
9. 移動端遠程調試、vConsole、TBS Studio
因為移動端的開發無法像 pc 端開發一樣使用 Chrome 的開發者調試工具，所以調試移動端需要一些額外的技巧。
移動端應用一般都運行在微信瀏覽器中、 webview 中、手機瀏覽器中。
遠程調試(Remote Debugging)
遠程調試就是通過 USB 連接、端口轉發、搭建代理等方式，將一個設備的 web 頁面映射到另一個設備上，比如將手機的 webview 映射到 pc 上，達到調試的目的。
移動端 web 應用調試難題從一開始就有，不過后來瀏覽器廠商基本都推出自己的遠程調試工具來解決這個問題，包括 OperaMobile、 iOSSafari、 ChromeforAndroid、UC 瀏覽器等，另外還有一些第三方開發的遠程調試工具，比如 weinre(http://people.apache.org/~pmuellr/weinre/docs/1.x/1.5.0/) 等。
以 Android 為例，可以將 webview、 ChromeforAndroid 中的頁面映射到 pc 端的 ChromeDevTools，然后就可以在 pc 端調試移動端的頁面了。
vConsole
一個輕量、可拓展、針對手機網頁的前端開發者調試面板( chrome 開發者工具的便利實現)。
這個是內嵌的頁面當中的便捷調試器，基本上能夠滿足一般的需要遠程調試的頁面。
- github：https://github.com/Tencent/vConsole
- demo：https://wechatfe.github.io/vconsole/demo.html
TBS Studio
因為微信瀏覽器是定制的瀏覽器，一般的遠程調試方式都不可用，需要配合特定的工具，如微信開發者工具。
TBS Studio(https://x5.tencent.com/tbs/guide.html) 是另一個可以像 Chrome 一樣調試遠程微信瀏覽器頁面的強大工具。
10. 前端后并行開發
正常情況下，前端的開發在完成 UI 或者組件開發之后，就需要等后端給出接口文檔才能繼續進行，如果能做到前后端并行開發，也能提升開發效率。
前后端并行開發，就是說前端的開發不需要等后端給出接口文檔就可以進行開發，等后端給出接口之后，再對接好后就基本上可以上線了。
在本地化接口模擬的實現下，就可以做到前后端并行開發，只是在代碼層面需要對 ajax 進行封裝。
11. 友好的溝通
不管工具多么厲害，很多時候都免不了要當面溝通，友好、心平氣和的溝通也是很重要的哩!
