问一下这种情况是公司的 Java 在忽悠我不懂后端吗?

[excitedXXX]

1.公司测试提了个 BUG,一个 list 删除某 item 显示成功但没从 list 中移除.接着从 log 中发现删除的 code 返回是成功的,提示成功后再次请求 list 被删除的 item 仍然给我返回了.遂觉得是后端的原因,便把 BUG 指给了他.然后这货告诉我是因为主从库延迟的问题,需要删除成功后前端自己先去移除 list 中的 item.我就问问这种问题大家遇到过吗?都是怎么解决的
2.接着过了一段时间 list 接口偶现 code5000,提示 sql 有错.这货就说一定是你前端的问题啊,前端传的参数不对,后端 sql 当然就报错了,没办法气势没人家强,打印 log 发现参数没有问题,告诉这货这货也不吭声,也不知道改了没.事后一想,不对啊,偶现的 BUG 怎么可能会是参数的问题,我寻思着参数不对你也应该每个提示吧,直接崩了就不太好了吧.
.....类似的事情太多了,什么 int 无值给个 null,性别无默认值也给 null,为 null 的连这个字段都不传过来....
这是我不懂后端,还是技术壁垒没办法?

[Cbdy]

是的

[rockyou12]

大哥你这后端不管懂不懂，排版一定要懂啊……

[excitedXXX]

@rockyou12 刚来社区没多久.....明明敲了回车结果是这个排版....现在改不了了....

[component]

很明显啊，两个半斤八两的前后端，你应该花点时间用 nodejs 捣鼓一个项目，搞清楚搞明白了，以后对这种半桶水的 CRUD boy 的虾扯蛋就可以理直气壮的对回去了。

[excitedXXX]

@component 我是 android.....

[Jaosn]

怼就完事了

[cedoo22]

凡是调接口的 ， 直接把出参、入参原始值打印出来说事，不要你觉得，要日志觉得。

[Livid]

@excitedXXX 在主题刚发布的十分钟内是可以修改的。你这个帖子的问题是，选择了 Markdown 格式，但是并没有了解 Markdown 对换行的处理。

[anyele]

确实后端水

[Livid]

@excitedXXX 我帮你切换成了 Default 标记模式。

[symeonchen]

具体情况具体分析。1.可以理解，前端先行移除也正常，多数场景删除一条数据并不意味着「立刻」重新拉取「全部」数据。2. 不了解，多沟通。其他，无值给 null 或是不传或是给默认值，没有绝对的对错，最好是事先约定+防御性编程。譬如有的时候 int 值为 0 和为 null 有不同业务含义呢。

[HuHui]

@Livid 加一个预览吧

[charlie21]

欸 所以前后都懂一点儿 还是很有必要的，防止被讹

[Livid]

@HuHui 我们所有的主题发布接口都有预览功能的。

[dilu]

第一个问题，你的方案有问题，但并不是你的错，删除 item 后直接前端移出 item，不要去请求后端接口除非用户刷新 一个是避免主从延迟导致的'删不掉'，一个是避免频繁请求接口造成服务端压力。只能说这是个不怪任何人的 bug。
第二个问题，绝对服务端问题，虽然我也是个服务端。这几年踩过的坑告诉我没有什么是偶然的，偶然出现一定有 bug，绝对要排查清楚才行。只能说你不够强势，服务端问题直接反馈给服务端解决，他们不解决先跟上级反馈，再跟测试产品沟通一下，直接拒绝这个 bug。

[k9982874]

第一个问题，如果做了读写分离是有可能的
第二个问题，sql 有错后端先查根源，前端参数传错后端没处理异常，锅一人一半。
josn 空值返回 null 是默认行为，前端不要求，后端不会处理，所以提前商量好。
总结，经验不足的锅。

[excitedXXX]

看了大家的评论很受教.......感谢感谢

[daimubai]

歪个楼，我们之前的后端和 iOS 吵架了，然后后端说你以后别找我调接口，然后 iOS 用了一个月的假数据。。。

[Leonard]

@daimubai 吊炸天

[ChangQin]

@daimubai 吊炸天+1

[Erroad]

第一个问题：总体方案设计有问题，主从延迟这种东西肯定会有的，到底是前端做个本地缓存处理，还是后端做强制读主库处理或者做一层缓存处理视情况而定；

第二个问题：前端的输入参数引起 sql 报错，那么就说明后端没有对前端数据做好参数校验和过滤，绝对后端有锅，参数到底怎么传可能是你们协商的问题、后端接口文档、你理解上的问题。

总体来说，我觉得你们后端问题比较大，毕竟后端应该担负起整个服务的责任

[mejee]

1，后端没有坑你，前端删除对于用户感受也会好些，不用重新加载列表。但是从库延迟的问题应该设计方案的时候就想到，不过 一般最多 也就几百毫秒的延迟，很多时候会忽略掉这个问题。

2，直接崩了是后端的锅，其他的不好说。

[CEBBCAT]

人类都登月几十年了，技术问题不存在。

第一个是一致性问题，要是我我就吭哧吭哧找解决办法去了，没听说过 YouTube 删什么东西还要删几分钟的，不过对于用户倒是可以解释成有缓存

第二个也是他在甩锅，对外暴露的接口应该对传进来的数据持怀疑态度。传 null 是团队开发规范吧，八成咱俩都是小公司，体量大点就会有要求，不然协作也太折磨人了

[mnssbe]

这个后端太水，怼得太直接也是影响工作

[mnssbe]

@k9982874 搞了读写分离这个问题就解决不了了？

[SyncWorld]

第一个问题没看懂....
第二个问题:要么是开发时间压缩的很近,要么是外包公司,要么就是后台脑残~~ 凡是开发时间给充足了,我都会校验参数的,但是 TMD 我们公司让我们一个月要做完 200 多个功能,那就.....凡是报错全部在拦截器层处理,统一返回请求失败,参数都不带校验的,必传相全部在数据库里设置 not null........这样很不负责,但是可以提高不少的工作效率.
再按以前那种,错误码排一堆,各种异常分别处理,我估计我们老板得让我们 007 了

[KasonPasser]

如果是参数问题，那应该也把对应的问题给返回。而不是拿错误的参数去执行 sql 完全相信前端传来的数据，分分钟就给别人脱库。

[icecreamxuegao]

字段无值不返回或者给 null 这种还是要看规范的，如果有规范就按照规范来，如果没有规范就两个人商量出一个规范出来就行了。

[lovemegowin]

还是不够强势 换我遇到这种后端能喷到他妈都不认识

[zigzog]

1 有可能是真的，2 应该是忽悠，从 2 反推 1 应该也是忽悠

[ZXCDFGTYU]

大写的忽悠

[liumxz]

卢本伟牛逼

[751327]

第一个问题有可能
第二个问题，你们这前后端关系也太僵硬....

[excitedXXX]

@751327 我也觉得,我才来没多久,之前的公司有啥问题都是互相帮忙排除,在这就是互相甩锅.有时候 bug 指错人了还发火....同组的打包也不通知,他改完打包给测试了然后我的 bug 全部算复现..QAQ.

[cedoo22]

说实话， 作为一个服务端开发，很容易对前端有点不耐烦，业务流程复杂的时候，调试会有许多不确定性的问题，接口提供出来给你调用，出了问题，永远第一句就是：这里为啥返回的是这样？？
大部分公司而言 前端不会做多么开创性的东西，就只是展示数据那么简单的事情，所有的逻辑基本都在后端，一不给日志 二不发参数，一来就质问的语气 问为啥不对。。。。

[hoyixi]

软件作坊就这样，整天加班其实都在扯淡

[akira]

@cedoo22 啊不然咧，分工就是这样的啊。。

[xiaojun1994]

这就扯淡了，我一般会自己删掉，但是挡不住用户刷新啊，一刷新又出来了岂不是很尴尬

[q8164305]

所以我自己学后端了，跟他们扯真的很费事

[zhw2590582]

@daimubai 这也太嚣张了吧

[amon]

一般调接口先用 postman 类的工具调通了再接入，所以如果 postman 类工具调用都有各种问题，把问题甩给后台就对了：）

[wupher]

是的，他在忽悠你。

这其实和前后端都没关系，没有想伤人的意思，但我真心觉得这个是智商问题。

问题 1：后端给予你的结果要保证逻辑严密性。哪怕是真有清 cache 等异步操作，后端也要保证给你的结果是准确有效的，要去除，也应该是后端去除。

问题 2：偶现不偶现和是否参数真没关系。后端可能完全把某个用户输入给拼接成 SQL 了，如果用户尝试注入或者输入某些含 SQL 关键字的乱码，就会造成异常。不过，的确如你所说，用户输入本来就不能信任。他要缺点德给你来个 SQL 注入都是有可能的。站在后端的角度，所有的前端调用都是不能信任的，参数必须经常验证和鉴权。

所以，综上所述，我觉得你的队友虽然甩锅是一方面原因，另一方面，你确实也应该自我提升一下。

当然，也可能是你在开贴骗分 ¯\_(ツ)_/¯

祝春节快乐

[xuanbg]

1、主从延时过高的话，是运维的锅，你找后端没用。
2、前端对 list 里面的 item 进行操作的同时，应该自己更新数据而非偷懒调接口刷新数据。一来体验不好，二来空耗流量。如果是新增 item，可以让接口返回 id，然后自己更新对象的 id 后插入到 list 里面。
3、接口爆炸的那个完全就是后端嘴硬罢了，SQL 错了就是代码写得不够安全。