公众号「古时的风筝」，专注于后端技能，尤其是 Java 及周边生态。
个人博客：www.moonkite.cn
大家好，我是风筝
听说这是前端程序员最厌烦的后端行为，不知道你有没有碰到过，或许你的前端搭档尽管没跟你说过，可是你现已被偷偷吐槽了。
前端吐槽：后端从不自测接口，等到前后端联调时，这个接口获取不到，那个接口提交不了，把前端当成自己的接口测验员，耽误前端的开发进度。
听到这个吐槽，似乎看到从前惭愧的自己。这个缺点从前我也有啊，有些接口，尤其是大表单提交接口，表单特别大，字段许多，有时分就偷懒了，直接编译过了，就发到测验环境了。前端同时联调的时分一调接口，异常了。
好在后来改了，毕竟让人发现自己接口写的有问题，也是一件丢脸的事儿。
可是我还真见过后端的同学，写完接口一个都不测，直接发测验环境的。
我就碰到过凶猛的，编译都不过，就直接提代码。从前，有个新来的搭档，分了任务就默默的干着，啥也不问，然后他做的功用测验就各种发现问题。说过之后，就改一下，可是基本上仍是不测验，本想再给他机会的，所以后来他每次提代码，我都review一下。直到有一天，我发现忍不了了，他把一段大局配置给注释了，然后把代码提了，我过去问他是不是本地调试，忘了撤销注释了。他的回答直接让我震惊了，他说：不是的，是因为不注释那段代码，我本地跑步起来，所以肯定是那段代码有问题，所以就注释了。
然后，当晚，他就离任了。
解决方式
对于这种大表单相似的问题，应该怎样处理呢？
好像没有别的办法，只能克服自己的懒散，为自己写的代码担任。就想着，万一接口有问题，别人或许会怀疑你水平不可，你水平不可，便是你不可啊，程序员怎样能不可呢。
你能够找那么在线 Java Bean转 JSON的功用，直接帮你生成恳求参数，或许现在更能够借助 ChatGPT ，帮你生成恳求参数，而且生成的参数或许比你自己瞎填的看上去更合理。
或许，如果是小团队，形形色色的话，能够让前端的搭档把代码提了，你本地跑着自测一下，让前端搭档先做别的功用，穿插进行也能够。
前端吐槽：后端修改了字段或回来结构不通知前端
这个就有点不讲武德了。
正常情况下，回来结构和字段都是事前约定好的，一般都是先写接口，做一些 Mock 数据，然后再实现真实的逻辑。
除了约定好回来字段和结构外，还包括接口地址、恳求办法、头信息等等，而且一个项目都会有项目接口标准，同一类接口的回来字段或许有许多相同的部分。
后端如果改接口，必需求及时通知前端，这其实应该是正常的开发流程。后端改了接口，不告知前端，到时分测验出问题了，一般都会先找前端，这不相当于让前端背锅了吗，的确不地道啊。
后端的同学们，谨记啊。
前端吐槽：为了获取一个信息，要先调用好几个接口，或许参数仍是相同的
假设在一个概况页面，从前端的角度便是，我获取概况信息，就调用概况接口好了，为什么调用概况接口之前，要调用3、4个其他的接口，你概况里需求啥参数，我直接给你传过去不就好了吗。
在后端看来或许是这样的，我这几个接口之前就写好了，前端拿过去就能用，只不过便是多调几回算了，没什么大不了的吧。
有些时分，或许的确是必须这么做的，比方页面内容太多，有的部分查询逻辑复杂，比较耗时，这时分需求异步加载，这样搞的确比较好。
可是更多时分其实便是后端犯懒了，不想再写个新接口。除了涉及到功能的问题，大多数逻辑都应该在后端处理，能用一个接口处理完，就不应该让前端多调用第二个接口。
有前端的朋友从前问过我，他说，他们现在做的系统中有些接口是依据用户身份来展现数据的，可是前端调用登录接口登录系统后，在调用其他接口的时分，除了在 Header 中加入 token 外，还有传许多关于用户信息的许多参数，这样做是不是不合理的。
这肯定不合理，token 原本便是依据用户身份发生的，后端拿到 token 就能获取用户信息，这是常识问题，让前端在接口中再传一遍，既不合理也不安全。
相似的问题还有，比方后端接口回来一堆数据，然后有的部分有用、有的部分没有，有的部分还涉及到逻辑，不借助文档底子就看不明白怎样用，这其实并不合理。
接口应该尽量只包括有用的部分，并且尽或许结构清晰，配合简单的字段说明就能让人明白是怎样回事，是最好的作用。
如果前后端都感觉形势不对了，后端一个接口处理功能跟不上了，前端处理又太麻烦了。这时分就要向上看了，产品设计上或许需求改一改了。
后端的同学能够学一点前端，前端的同学也能够学一点后端，当你都懂一些的时分，就能两方面考虑了，这样做出来的东西或许会更好用一点。总之，前后端相互理解，毕竟都是为了日子嘛。
