实践应用：前后端分离式开发高效协作10条准则-CFANZ编程社区

前后端分离的开发方式现在火得一批，关于前后端分离，前文比较详细的阐述过为什么要这么做，以及相关开发规范示例，有兴趣可以翻阅一下我之前的文章：

本文继续阐述前后端分离开发模式中 我们常用的 10条最佳实践准则！

避免后端渲染

Web应用的渲染方式分为服务器端渲染和客户端渲染，当下比较推荐的方式是客户端渲染，数据使用全ajax的方式进行交互。

除非在一些不得不使用服务器端渲染的情况下（如门户、电商等），应当尽量使用客户端渲染，因为客户端渲染更能使前后端分离（项目分离、代码解耦、协作分离、职责分离等），也能更好的做本地接口模拟开发，提升开发效率。

即使用服务器端渲染，在技术支持的条件下，可以使用 node中间层（由前端人员开发），代替传统的后端模板渲染，这样可以使后端与前端完全解耦，后端与前端只有数据上的往来。

避免大量线上调试

做好本地接口模拟开发（包括后端模板渲染），避免大量的线上调试，因为线上调试很不方便，也很费事，并且每次更新代码，都需要重新构建，然后同步到服务器。

所以做好本地接口模拟开发，只要程序在本地运行是没问题的，一般线上就不会有太大的问题，这样就能大幅降低调试工作量，提升开发效率。

规范接口文档

前端与后端协作提升开发效率的一个很重要的方法就是减少沟通：能够形成纸质的文档就不要口头沟通、能够把接口文档写清楚也不要口头沟通（参数、数据结构、字段含义等），特别是线上协作的时候，面对面交流是很困难的。

一个良好的接口文档应当有以下的几点要求与信息：

格式简洁清晰
分组：当接口很多的时候，分组就很必要了
接口名、接口描述、接口地址
http 方法、参数、headers、是否序列化
http 状态码、响应数据

接口文档可以用一些现有的文档服务来管理文档（可参考文章《前后端都分离了，该搞个好用的API管理系统了！》），也可以用 Git 来管理；书写方式可以用 markdown，也可以 YAML、 JSON 等。

推荐使用 markdown 方式写文档，用 git 管理文档。

本地接口模拟开发

本地接口模拟就是在本地模拟一个与服务器差不多的环境，能够提供数据所需的接口，进行错误模拟处理等等。借助已有的一些好用的API管理工具，可以方便地搭建本地接口数据Mock平台，具体选择可以参考文章《前后端都分离了，该搞个好用的API管理系统了！ 》

本地接口模拟开发的意义就在于能够在本地完成几乎所有的开发与调试，尽量减少线上的调试，提高开发效率。

一些常用库：

browser-sync: 能让浏览器实时、快速响应文件更改（ html、 js、 css、 sass、 less 等）并自动刷新页面，并且可以同时在PC、平板、手机等设备下进行调试。
webpack-dev-middleware: A development middleware for webpack
webpack-hot-middleware: 热更新本地开发浏览器服务

另外，本地接口模拟开发需要后端开发人员有规范的接口文档。

前后端并行开发

正常情况下，前端的开发在完成 UI 或者组件开发之后，就需要等后端给出接口文档才能继续进行，如果能做到前后端并行开发，也能提升开发效率。

前后端并行开发，就是说前端的开发不需要等后端给出接口就可以进行开发，等后端给出接口之后，再对接好后就基本上可以上线了。

在本地化接口模拟的实现下，就可以做到前后端并行开发，只是在代码层面需要对 ajax 进行封装。

去缓存

前端需要做好去客户端缓存的功能，保证用户始终都是使用的最新资源，不会因为因为缓存的问题而出现 bug。

传统的去缓存是在静态资源 url 上加上版本号或者时间戳，不过因为构建工具的出现以及一些浏览器已经不支持这种方式了的缘故，这种方式已经是过去时了。

现在去缓存是将文件 hash 化命名，只要文件变动，文件名就会不一样，以此才能彻底的去缓存。如果使用 webpack工具 进行打包，会自动将所有文件进行 hash 化命名。

做好错误处理

前端与后端都需要各自做好错误处理，以便发生错误能够有友好的提示，也能在用户反馈时快速准确定位错误来源和原因。

一般前端的错误分为：

脚本运行错误：js 脚本错误，找到堆栈信息，然后解决
接口错误：服务器报错、数据返回不对、没有响应数据、超时等

而后端的错误分为：

状态码错误：服务器报错、超时等
数据错误：没有响应数据、数据格式不对、数据内容不对

切记写代码时多考虑代码的鲁棒性！

运行时捕捉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 查看原始的报错堆栈信息。

移动端远程调试、vConsole、TBS

因为移动端的开发无法像 PC 端开发一样使用 Chrome 的开发者调试工具，所以调试移动端需要一些额外的技巧。

移动端应用一般都运行在微信浏览器中、webview 中、手机浏览器中。

一、远程调试（Remote Debugging）

远程调试就是通过 USB 连接、端口转发、搭建代理等方式，将一个设备的 web 页面映射到另一个设备上，比如将手机的 webview 映射到 pc 上，达到调试的目的。

移动端 web 应用调试难题从一开始就有，不过后来浏览器厂商基本都推出自己的远程调试工具来解决这个问题，包括 OperaMobile、 iOSSafari、 ChromeforAndroid、UC 浏览器等，另外还有一些第三方开发的远程调试工具，比如 weinre 等。

以 Android 为例，可以将 webview、 ChromeforAndroid 中的页面映射到 pc 端的 ChromeDevTools，然后就可以在 pc 端调试移动端的页面了。

二、vConsole

一个轻量、可拓展、针对手机网页的前端开发者调试面板（ chrome 开发者工具的便利实现）。

这个是内嵌的页面当中的便捷调试器，基本上能够满足一般的需要远程调试的页面。