日常工作中关于前后端分离的简单介绍-CSDN博客

background

最近部门的项目比较多，而且慢慢开始有较多的项目有接口对接的需求，有的同志包括我刚开始接到这样的任务的时候可能会不太熟悉，考虑到后面这样的工作比重会越来越大，今天就来介绍一下日常开发中涉及到接口对接的内容，以下内容是我自己在工作中总结出来的拙见，如有不当之处请各位大佬指正！

throw the result firstly!

先抛出结论，接口对接，就是把我们平时任务中用的模拟数据换成真实接口，而已。乍一看感觉蛮简单的，但是实际上在投入到工作中后会遇到各种各样的问题，后面会依次介绍。

why?

前后端分离，就是前端和后端分离，前台逻辑全部逻辑由前端实现，而后台只需要专注于接口，确保提供符合规范及需求的数据接口给前端调用，一方面能够提高工作效率，另一方面也大大增加了前台页面的可维护性。我们部门很大一部分前后端分离工作都涉及到门户网站、oa对接。先来随便看看一些经常碰到的网站是啥样的。

可以看到，这些网站都有一些共性，大量的列表信息，还有不同的栏目，用户登录，这些功能的实现都遵循对应的规则，也就形成了接口规范，关于这个可以在oa上查看标准版oa对接文档或者在部门网站查看相关介绍。

how？

在工作中，以oa对接为例，我将其中涉及到前端的工作内容总结为这几块。

重构，这个就不多说了。
根据接口开发提供的接口文档进行数据对接。
有的时候你可能需要自己登陆后台录入一些模拟数据。
一些个性化的需求的沟通，调整（这个最难，最耗时）。
一些莫名其妙的需求修改（这个最恶心）。

以oa网站来说，简单的示意图如下（我是这么认为的...）：

从图中可以看出，oa和接口、数据库都部署在服务器上（也可能在不同的服务器上），前台网站是用户访问服务器获取的，调用接口，拿到数据再展现在前台，数据信息的维护可以在oa后台来维护，有时候前端开发也会做一些这样的工作，大致流程就是这样。

type

目前我接触到的前后分离的工作大概可以总结为以下几种。

1 标准版oa对接这种类型的任务比较常见，直接根据标准版oa接口的文档，标准版oa接口文档包含了非常全面的内容，能够满足大部分oa对接门户网站的需求。在只需要标准版对接的情况下，是非常方便的，只需要把平时开发中获取的模拟数据从接口中获取即可。
2 个性化oa接口虽然标准版能够满足大部分需求，但是还是存在较多的网站有一个需要个性化的需求，比如列表信息需要展示额外的字段等，这个时候就需要接口开发对接口做一些个性化修改，实际开发以接口开发提供的文档为主。
3 按照公司规范，自己设计数据格式模拟接口，后台根据前端设计的数据格式实现接口，此类开发一般以前端主导。

notice

从我不多的前后端分离开发经历来看，我觉得前后分离最难得地方就是沟通，接口的调整个性化需要沟通，需求变动、页面调整也需要沟通。沟通的好坏直接影响到后续工作的效率及质量。接下来分享一下我能想到的一些注意点或者常见的问题。

1 跨域问题遇到这种问题，不要想着自己配代理、anyproxy什么的，这些我觉得是第二方案，直接找后台在服务器配一下跨域规则即可，一步到位，避免浪费时间。
2 现有接口满足不了需求接口满足不了需求，对前端来说最好的解决方案就是改接口，比如说要在列表加一个会议室字段，比如这样的，oa标准版接口没有这样的字段，有的接口开发可能会让你直接在列表标题前加上几个字就行，但是这样的方案只是治标不治本，而且如果这样做会加大自己的工作量，给自己挖坑。
3 适当的评估需求的合理性，不要来什么就做什么经常会有一些莫名其妙的需求，并且在用户体验上来不合理，遇到这种情况还是要跟项目组沟通，引导客户把需求往合理的方向去提，当然这个工作主要是实施同事来做。一些不合理并且不重要的需求，可以适当拒绝。
4 代码可读性，可维护性也非产重要我目前做的几个对接oa的任务，基本每一个都是不停的在改改改，一个项目从第一次交付到最终上线，代码实现逻辑可能会“大变样”，后面的修改都会跑到我们手里，所以把代码写的方便维护真的非常重要，不然真的会被自己坑。

tips

一般接口对接开发时调的都是测试环境的接口，将所有涉及到调用接口的ajax语句中的url的公共部分提取成全局变量，方便切换真实环境和测试环境。
能一次获取的数据，不要获取两次。最最典型的例子就是用户信息，一般门户网站都是首页-二级页-详情页三级模式，每一页的头部可能都会有一块展示用户信息，这些相同的数据，可以只请求一次，多个页面共用。
相同的操作可以提取成公共函数，这个可以参考部门骨架里common.js。
每个功能都可以看成一个模块，细化再细化，做到每个函数模块的功能只专注于一个任务，定义合理的参数，暴露适当的接口等等，这样在维护修改的时候只需要修改对应的模块而不用担心影响到其他模块，非常舒服。
尽可能的考虑各种情况，比如文本过长等，开发的时候不考虑，改bug的时候心里苦啊。
非常重要的一点，拿到任务先别急着开发，磨刀不误砍柴工，理清楚逻辑思路再做。
自己模拟数据注意数据结构，利于维护。
ie虐我千百遍，我待ie如初恋。大部门用户电脑都是ie8，所以这个兼容性还是要多考虑的。
非常容易踩的一个坑，纯正的ie8是不支持console.log语句的！！！请在交付的时候（不管是不是ie），将console调试代码注释或删除！
echarts配置写对了不生效，99%的解决方案就是去官网下最新的js文件！
可以对高版本浏览器做一些渐进增强的效果，比如加个transition变色什么的，我觉得很好看。