专栏名称: SegmentFault思否
SegmentFault (www.sf.gg)开发者社区,是中国年轻开发者喜爱的极客社区,我们为开发者提供最纯粹的技术交流和分享平台。
目录
相关文章推荐
OSC开源社区  ·  RAG市场的2024:随需而变,从狂热到理性 ·  20 小时前  
码农翻身  ·  漫画 | 为什么大家都愿意进入外企? ·  昨天  
程序员小灰  ·  3个令人惊艳的DeepSeek项目,诞生了! ·  2 天前  
程序员的那些事  ·  惊!小偷“零元购”后竟向 DeepSeek ... ·  3 天前  
程序员小灰  ·  DeepSeek做AI代写,彻底爆了! ·  5 天前  
51好读  ›  专栏  ›  SegmentFault思否

前端如何高效的与后端协作开发

SegmentFault思否  · 公众号  · 程序员  · 2018-11-06 08:00

正文

1. 前后端分离

前端与后端的分离,能使前端的开发脱离后端的开发模式,拥有更大的自由度,以此便可做前端工程化、组件化、单页面应用等。

可以参考:前后端分离、web与static服务器分离( https://segmentfault.com/a/1190000015297319 )。

2. 尽量避免后端模板渲染

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

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

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

可以参考:细说后端模板渲染、客户端渲染、node 中间层、服务器端渲染(ssr)( https://segmentfault.com/a/1190000016704384 )。

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 ):热更新本地开发浏览器服务。

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

可以参考:本地化接口模拟、前后端并行开发( https://segmentfault.com/a/1190000015297352 )。

5. 规范的接口文档

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

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

  1. 格式简洁清晰:推荐用 API Blueprint( https://apiblueprint.org/ )

  2. 分组:当接口很多的时候,分组就很必要了

  3. 接口名、接口描述、接口地址

  4. http 方法、参数、headers、是否序列化

  5. 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 了:

  1. window.onerror = (errorMessage, scriptURI, lineNumber, columnNumber, errorObj) => {

  2.  const data = {

  3.    title: document.getElementsByTagName('title')[0].innerText,

  4.    errorMessage,

  5.    scriptURI,

  6.    lineNumber ,

  7.    columnNumber,

  8.    detailMessage: (errorObj && errorObj.message) || '',

  9.    stack: (errorObj && errorObj.stack) || '',

  10.    userAgent: window.navigator.userAgent,

  11.    locationHref: window.location.href,

  12.    cookie: window.document.cookie,

  13.  };

  14.  post('url', data); // 上报到服务器

  15. };

线上的 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







请到「今天看啥」查看全文