吐槽

12 条回复
92 次浏览

在当前项目中,后台系统编辑规则,小程序使用规则;

  1. 按我以前接触过的后台保存的数据结构一般是数组格式,小程序正常查询使用;
  2. 但是在当前项目的后端接口中,类似功能全部使用 Json 格式,无论对象还是数组,不是说做不到,但是所有的参数全部要经历一次序列号/反序列化,感觉完全没必要的做法,当前也是嫌麻烦,和后端说,就是数据库存的就是 Json 改不了,明明参数都是新增的;
  3. 这让我感觉就是为了偷懒,因为他以前说过一次,Java 是强类型语言,新定义变量要写很多的类型,是不是类似前端中的 Typescript 一样?
  4. 前端没话语权在这种毫无规范的团队中真的太难受了
  5. 数据格式处理、返回数据的层级、列表和详情的读取,各种全是前端做兼容,后端唯一做的就是把数据丢在返回数据中,其他出任何问题都是前端的错,读取层级不对、读取的数据格式不对产生的报错、页面跳转之后的各种数据缓存、缓存丢失造成的页面空白,各种异常全部都要考虑mental_boom
等级丰碑

你要学会长嘴,谁能说服的了谁,谁就是轻松的哪一方

OP

说了,然后就是你怎么那么喜欢推卸责任呢,说了让你做你做就完了,人家即是后端也是主管,卑微前端能怎么办呢feel_wronged

幸运儿

前后端本身就要有个数据标准,但是一般看公司的,如果你们标准是这样,那只能接入层做适配了,如果经常乱写,那可以要求制定标准和遵循标准了
Java 是强类型语言,class 结构也确实强约束,确实要改动的地方多,不过现在都是 agent 做事了,不是什么麻烦事

看起来你们是后端为主,前端像打杂了,确实难受

OP

是的,提数据结构,后端说框架限制只能这么做;喜欢按标准实现,人家说一两个人怎么方便怎么来mental_boom

展开 1 条评论
2Libra 一周年!

如果是能结构化存的数据却用 json 存,那这后端挖的坑有点深啊,后面统计查询起来都难咯sobbing

OP

那就不查呗,就说这功能做不了,常规做法我都习惯了cunning

OP

这也是我见过最牛逼的后端了,需求跟着他变,想做就做不想做就让产品改nose_pick

发表一个评论

R保持