对事也对人，文中出现的需求非实际原始需求，是基于原始需求模拟出来的假需求；
案例5，2019-06-28
这次是导出文件的需求；
一开始的方案是 GET 请求，在浏览器中打开，会自动下载文件；后来发现有的导出会带很多参数，可能会超出 GET 方式所能传递的长度；于是我提出了另一个方案，改成 form 表单 post 提交；
调试过程也非常有意思：
1、我先改了一个模块下的四个页面，分别对应无参数、带一个数字类型的参数、带三个字符串类型的参数、带一个字符串和两个数字类型的参数（传递的时候，其实都是字符串类型的，但以我的经验，后端肯定会有问题，所以特意这么区分），改完后传到测试环境，之所以选这四个页面的导出，是因为这几个页面参数少，简单方便调试，实际使用中，参数都做了长度限制，并没有超出get字符限制的问题；在群里向后端做了说明，让后端用这四个进行测试联调；
正常来说，提出解决方案后我可以不用做处理，让后端自己修改测试自己的接口去，没问题了我再改，但这样后端肯定会来要测试地址，我嫌麻烦，提前给他们做好；心想这么简单，最多半小时就能搞定吧；
2、下午两点后端来了，说设了断点，请求都走不到接口里面，质疑这种解决方案，我说除了 get 方案，就只有这一种了，而且form表单很简单，没复杂的配置，前端能做的都做了；
后端说这种方案行不通，进不到接口里，我们调了一上午，把测试环境改回去吧，这四个页面的导出并没有超出长度的问题，不要影响测试人员进行测试，咱们再找别的方案；
WTF！！我说这四个是为了方便你们测试改的，也没有其他解决方案了，你们自己找吧，到时候通了告诉我前端怎么配合改，说着我就抓紧把四个页面的导出功能回滚更新到测试环境了，那可是不能耽误测试呢（修改的事情我已经在群里说了，而且如果有人没看到信息测试了导出功能，会报错，肯定会反馈到群里了，实际上并没有）；
期间另一个后端过来，我也和他解释了一遍，form 表单提交里边，配置这个、配置那个；然后他俩在这儿讨论，又让我留一个 form 表单提交类型的，我说不行，改成 form 表单不通，别耽误他们测试，我单独给你们一个 html 文件，放到你们本地或测试环境自己去测试；一开始那个后端一听来劲了：必须要原环境，不是原环境就不行，测试的时候可能有问题！呵呵，这句话满是槽点，我实在是不知道从哪儿切入，早知道一开始就该让他们用 postman 模拟去，惯得不行；
3、吵了好久，我领导过来，了解情况，最终我做了一个妥协，在页面的空白处加了两个 form 导出，一个是不带参数的，一个是带字符串参数的，心想这下如你们的意了，可以解决问题了吧；
这次是另一个后端来调试，前前后后质疑了我三次，点击这个按钮，是post方式吧，还是没有进后端呢；是 post 方式吧，我用 postman 可以进后端呢；是 post 方式吧，接口返回不支持 get 方式呢；
4、后端最终是搞出来了，呵呵，现在后端门槛这么低了吗？
今天的两连击，让我怀疑人生了；
案例4，2019-06-28
又来刷新三观了；
编辑一条记录的时候，正常来说，只提交用户可编辑的字段就行了；编辑的时候，先根据id查出该数据显示用到的字段，然后显示到页面上，用户编辑完了，把编辑（修改过）的字段提交给后端；
整个过程中，有两个地方平时可能不会做那么细：
- 根据id查字段，后端为了省事儿，会返回全部字段，包括什么创建时间、修改时间之类的，前端一般用不到；
- 用户编辑完成，前端提交的时候，一般是把所有可修改的字段提交到后端，不做用户是否修改了该字段的判断
这次要说的就是编辑这个逻辑，目前后端在根据id查数据的接口中返回了所有字段，包括一些页面上没用到的字段，还算正常；
上午后端过来和我说，要把查询出来的所有字段比如创建时间、创建人、该记录是否删除的标识等系统自动生成或用户不能修改的字段原样提交回去？！？！
后端还振振有词：就是这么实现的，不传这些字段，后端不知道这些字段是要清空还是没有做修改（没错，后端说不知道有没有做修改？！看样子是做了一个全量字段更新的逻辑）。
呵呵，我觉得刚毕业的大学生也不可能会这么设计吧（最近看了几个还没毕业的大学生的产出，自愧不如、自愧不如啊）；这是在看不起前端这个职业么？是在看不起后端这个职业么？是在看不起公司么？我们好歹是一家大~公司，这种解决方案，好意思说出来吗；
我当即回绝，和后端解释，后端不听，说一定要这样，不这样不行。我说改不了，你让产品经理来找我吧。“谁改谁是小狗”我心想。
案例3，2019-05-09
又有新项目了，在和后端的对接中，有一个人是非常难配合的，给人的感觉像是实习生，或者校招刚进来的；难配合体现在哪些方面呢？下面就列举一下：
1、接口文档不完善
这种问题还真是第一次遇到，我理解的接口文档，标明url地址、请求方式、请求参数、响应数据这些东西就可以了，给到前端就能用；但这次遇到的是什么问题呢？
- 接口参数格式不统一，两个模块的删除接口，一个是这种形式：{reqData:{id:1}}，外层的 reqData 到底有什么作用呢；还一个删除是走的编辑接口，参数是这种形式：{reqData: {id:1, deleted: true}}，后端说数据没有物理删除，都是改 deleted 字段，这个字段让前端传过去，这和前端有什么关系；
- 没有写参数名，比如还是刚才的删除接口，沟通后改了，更新了接口文档，请求参数写着“xx的id” ！？；
2、接口不测试
按照接口文档里的url和请求参数发请求，这个同事负责的接口，除了简单的查询接，其他没一个通的；我在想你难道不测试一下吗？
3、修改接口需要别人配合
这个问题严重到什么程度呢？前端调接口，发现返回错误，通知后端，后端说你连我机器，再请求一下，我设断点调一下；
……上传文件这种不太好模拟的接口也就罢了；普通的接口postman实现不了么？get 请求直接在浏览器访问就能测试了，为啥非得浪费前端的时间来点这个按钮呢？
4、记性差
也可能是理解能力差，差到什么程度呢？当面沟通了某个接口的返回数据格式，扭头就给我改成另一种了，出现一次我也就不列举这条了，频繁出现到底是什么鬼？
在开发群里搜聊天记录，问题提出来一次就解决并反馈的情况就少；大部分是我汇总一个后端问题列表，后端可能都不查、不实际测一下，就一一回复：
第一个问题可以，你再试试；
第二个问题数据结构接口文档里有（实际上没有）；
第三个问题我已经改过了，你再试试；
……
5、基本没有理解业务逻辑
没有理解业务逻辑会导致什么问题呢？很明显，接口不能用；
项目中表现在什么地方呢？某些页面展示，后端会问我，这个地方你需要什么数据？问我需要什么类型的数据也就罢了，问我需要什么数据…？
我觉得，业务逻辑方面，除了产品经理，对业务最熟悉的应该就是后端了，其次是测试，最后是前端；
后端提供的接口内部，会根据业务逻辑做一些处理，除了接口，后端前期还需要搭建数据库、搭建管理后台，对数据源、数据格式、数据去向了如指掌，而这些，前端基本不会知道、测试也不会知道其中的一部分逻辑；
测试人员会根据页面上的录入、操作核对数据库中的原始数据，
前端就少很多了，只要页面上的逻辑能通，后端怎么处理数据的，哪个数据需要特殊处理，全都不关心；
总结
这个项目属于内部系统，自从做内部系统以来，遇到各种后端问题，不断的刷新了我的下限；之前做 toB/toC 的一些活动、平台、系统；都没有这么费劲过；
接近两周只调了4个页面，每个页面都有这些功能：支持列表查询、新增数据、删除数据、修改数据、导入数据、导出数据；这种普通页面，我理解这里面很多逻辑都是通用的，结果反复修改、报错、修改；现在我的要求已经降低到零下273摄氏度了，只要接口能通，返回数据中包含有效数据就可以，哪怕是最原始的数据；基于业务上的数据汇总、处理、格式化，可以都在前端做；
我现在没有话语权，只能向自己上级反映一下，希望后端那边能在提供接口前自测一下（正常开发流程就是这样啊），但这种情况，考虑到部门间的关系，且也不是所有后端都存在这些问题，就不处理了；我要是有话语权（不太可能了），绝对会规定：后端提供接口的之前，必须要经过自测，后期修改接口，一定要注明原因，是因为逻辑发生变化，还是之前自己没有理解；接口报错率、后期修改原因，全部计入KPI；
案例2，2019-03-06
这里说一下后端不专业的开发及迭代；
还是案例1中的需求开发，前端对接的时候，发现一组接口返回数据有问题，本来直接修改返回数据就完事儿了，结果后端又新增了一组接口，
本来接口是这种形式： http://xxx.com/getList
修改数据格式，新增了接口：http://xxx.com/getListJson
…… 只是这样也就算了，后来又发现权限有问题，普通用户的ajax请求被拦截，所有接口返回没权限，但普通用户是能够使用某些功能的；
此时，后端又进行了一顿操作，告诉我所有接口后都加一个 /json，即
本来接口是这种形式：http://xxx.com/getInfo
修改之后，新增了接口：http://xxx.com/getInfo/json
第一次修改的接口，就变成了：http://xxx.com/getListJson/json
接口地址更新也就罢了，老版接口还是同时存在的，相当于有一半多的接口用不到，但是还在线对外提供；幸亏是个内部系统；
后端修改接口时一直强调自己手里有其他项目，时间紧，我觉得是态度和职业素养问题，任凭我怎么想，接口的修改和迭代也不会这样啊；
案例1，2019-02-25
需求
现在有一个系统，支持用户自定义配置某些项目，自定义配置的条目后台是动态管理的；
现在的需求是做这么一个管理页面，用户可以修改自定义的配置项，比如新上线了更换系统背景图的功能，每个用户可以自定义背景图片，但第一次进入该管理页面，背景图内容为空，但是要展示这个项目（肯定要展示，要不用户怎么进行配置背景图）；
当前系统设计
一个用户表 User，记录用户信息，
一个自定义配置项目表 Settings，记录可以配置的项目，
一个用户配置项目映射表 Mapping，记录用户的自定义配置内容；
后端提供的接口和方案
1、用户自定义配置项接口：返回用户的配置项以及对应的配置内容；如果是第一次访问，返回空（第一次访问时，用户配置项目映射表 Mapping 中没有该用户的数据）；
2、初始化接口：用户进入页面，先调用1中的接口，如果返回空，说明是第一次访问，需要先调用该接口，成功后再调用接口1；
即用户第一次访问该页面，逻辑是：调用用户自定义设置项接口 –> 调用初始化接口 –> 调用用户自定义设置项接口；三次调用是串行；
正常方案
只需要提供一个获取用户配置项的接口，接口内部自行判断，如果没有从 Mapping 表中取到该用户的配置项，则初始化插入，然后返回初始化字段；
对前端来说，不关心用户在 Mapping 表中有没有数据，只需要接口返回一个配置项和配置内容的列表；
总结
后端的这个方案怎么想都不合理，怎么设计也不会得出这种方案；
抛开业务逻辑，对前端来说，为什么不合理？
因为该案例中的初始化接口，对前端来说，既没有把数据传给后端，也没有接收到后端返回的数据；
前端调用接口，要么是传数据，要么是获取数据，非这两种情况，接口就不应该存在；