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