问一下这种情况是公司的 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