先後端高效協做開發的11條建議

時間 2019-11-06

標籤後端高效開發建議简体版

原文原文鏈接

內容來源：做者，深予之 (@senntyou)，https://github.com/senntyou/blogs；來自，https://segmentfault.com/a/1190000016852780
css

閱讀字數：4430 | 12分鐘閱讀html

摘要

最後一條最牛逼……前端

1. 先後端分離

前端與後端的分離，能使前端的開發脫離後端的開發模式，擁有更大的自由度，以此即可作前端工程化、組件化、單頁面應用等。node

能夠參考：先後端分離、web與static服務器分離（https://segmentfault.com/a/1190000015297319）。webpack

2. 儘可能避免後端模板渲染

web 應用的渲染方式分爲服務器端渲染和客戶端渲染，當下比較推薦的方式是客戶端渲染，數據使用全 ajax 的方式進行交互。git

除非在一些不得不使用服務器端渲染的狀況下（如門戶、電商等），應當儘可能使用客戶端渲染，由於客戶端渲染更能使先後端分離（項目分離、代碼解耦、協做分離、職責分離等），也能更好的作本地接口模擬開發，提高開發效率。github

即便用服務器端渲染，在技術支持的條件下，可使用 node 中間層（由前端人員開發），代替傳統的後端模板渲染，這樣可使後端與前端徹底解耦，後端與前端只有數據上的往來。web

能夠參考：細說後端模板渲染、客戶端渲染、node 中間層、服務器端渲染（ssr）（https://segmentfault.com/a/1190000016704384）。ajax

3. 儘可能避免大量的線上調試

作好本地接口模擬開發（包括後端模板渲染），避免大量的線上調試，由於線上調試很不方便，也很費事，而且每次更新代碼，都須要從新構建，而後同步到服務器。chrome

因此作好本地接口模擬開發，只要程序在本地運行是沒問題的，通常線上就不會有太大的問題，這樣就能大幅下降調試工做量，提高開發效率。

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)：熱更新本地開發瀏覽器服務。

另外，本地接口模擬開發須要後端開發人員有規範的接口文檔。

能夠參考：本地化接口模擬、先後端並行開發（https://segmentfault.com/a/1190000015297352）。

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 化命名。

能夠參考：webpack output-filename（https://webpack.js.org/configuration/output/#output-filename）。

7. 作好錯誤處理

前端與後端都須要各自作好錯誤處理，以便發生錯誤可以有友好的提示，也能在用戶反饋時快速準肯定位錯誤來源和緣由。

通常前端的錯誤分爲：

腳本運行錯誤： js 腳本錯誤，找到堆棧信息，而後解決
接口錯誤：服務器報錯、數據返回不對、沒有響應數據、超時等

而接口錯誤分爲：

狀態碼錯誤（狀態碼非 2XX）：服務器報錯、超時等
數據錯誤：沒有響應數據、數據格式不對、數據內容不對

能夠參考：HTTP狀態碼（https://baike.baidu.com/item/HTTP%E7%8A%B6%E6%80%81%E7%A0%81/5053660?fr=aladdin）。

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）查看原始的報錯堆棧信息。

能夠參考：

webpack - devtool（https://webpack.js.org/configuration/devtool/）
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 端調試移動端的頁面了。

能夠參考：移動端Web開發調試之Chrome遠程調試(Remote Debugging)（https://blog.csdn.net/freshlover/article/details/42528643/）。