今天天气晴朗，大雄有个朋友火气正旺，疯狂给我吐槽公司后端，为了方便阅读，前端朋友称作前端，后端朋友称作后端，事情大概是这样：
后端说要联调接口，前端说你的数据尽量按我的要求来，后端不服气，说你这个没用。前端就讲道理呀，传统的前后端分离返回的格式要尽量规范，这样才好处理。
后端同意了，很快啊，啪的一下，前端这边请求刚发出去，立马就返回了。
谁知大意了没有闪，一个Code码，一个字符串，一个数组，全部接受转换成了模型，再正常处理业务逻辑和页面展示，前端笑了笑提交测试，很快啊，一上正式环境程序就崩溃了啊。
原是字符串没有判空，前端说后端你不讲码德，后端说对不起，是我不懂规矩，我是乱打的代码。好家伙，一个训练有素的练家子会乱打？这明明是来糊弄咱老前端，不讲码德！
朋友只能劝他耗子尾汁，好好反思，以后不要再耍这种小聪明，毕竟程序员要以和为贵，搞窝里斗是万万不可的，求求不要再把空值异常抛给前端了！
其实在开发过程中，前后端还会存在其他分歧，比如前端希望根据 UI 来划分接口，这样用户体验好，前端实现也容易。后端则更希望根据业务模块划分接口，这样有利于服务下沉和解耦。
于是前后端间可能会出现如下对话:
--后端: 你多调几个接口不就行了么~ --前端: 多好几个 HTTP 请求呢。包成一个接口有这么难么？
前端和后端各有各的道理，还都不肯退让，互相扯皮，互相看不顺眼，所以结合大雄的见解，今天来分析分析为什么前后端总是争吵不断？
原因一：没有文档或文档不全
例如新的前端人员到了一个新的公司，使用接口时，问这个这个不知道，问那个那个不知道，要文档没文档，这绝对是前端人员最抓狂的事，心里肯定是一千只草泥马奔腾而过。
那为什么需要文档？
首先文档是当前开发者甚至后面的接盘侠（后面开发者）能够清晰往下做的第一步指引。
而且，从办公效率方向考虑，即便是简单的东西，但如果不写文档，以后口口相传消耗的工作量会比写文档更多。
再其次就是最简单的理由，好记性不如烂笔头，一段时间后，可能连开发者都忘记接口的用途，可不就尴尬了。
总之，文档是极其关键的，无论是在线文档还是本地文档。虽然写文档是麻烦的事，但对后端人员来说，是利人利己。
但在工作中时常也会出现这种状况，虽有文档，但徒有其表，文档里对接口的描述不全，可能缺每个参数详尽描述（取值范围、类型）、请求方式（GET、POST、PUT、DELETE）、返回数据的所有状态等等，这里面可能最缺就是返回数据的状态！
既然写了文档，就把文档写好，写明朗。
原因二：接口参数没校验，问题不断
这个前端人员倒不是很关注，因为本身调接口之前一般都会先做校验，后端做参数校验只是双重保证。不过还是提醒后端人员，做好参数校验是第一步，不要偷懒了。
但有时也不免出现以下情况：
--前端：我吊你，怎么你分享的接口这么多错误？
--后端：我吊你，你用之前不会测一测接口正不正常？
--前端：我为什么要测？你开发的接口，你自己不测好？
--后端：我怎么知道你要用什么样的数据！你要是稍微测一下接口，能有这么多事？
……
虽然前端开发人员调接口时候，可能会存在各自各样的问题，这是很正常的，有问题可以理解，程序哪会没有bug，但希望不要太离谱。
原因三：没保证接口原子性
一个原子事务要么完整执行，要么干脆不执行。这意味着，工作单元中的每项任务都必须正确执行。
如果有任一任务执行失败，则整个工作单元或事务就会被终止。即此前对数据所做的任何修改都将被撤销；如果所有任务都被成功执行，事务就会被提交，即对数据所作的修改将会是永久性的。
所以接口的原子性是很重要的，有时一个接口可能会干几件事，但不一定都能正常完成，这就导致可能存在原子性问题，接口不能准确被调用。
最后给现在的或者未来的前后端大师提一嘴。
要知道，前后端是互联网公司关系最紧密的两个岗位，二者相互配合好，才能给使用者更好的体验，所以还是希望双方都能多多体谅，换位思考。
在问题出现之前就尽量规避，在出现问题时，先检查自身，妥善处理。大家都是搬砖人，打工人何苦为难打工人呢。
>END<
