这是一个创建于 645 天前的主题，其中的信息可能已经有所发展或是发生改变。
背景： 我本来是以后端应聘进入公司的，在独立开发完两个项目后工作内容有变动，转了前端。
然后现在做前端内容一个月时间，发现是个巨坑。 主要包括但不限于：
- 后端的接口不遵循 restful
- 帕斯卡、下划线命名混用，在一个字段可以见到 2 种命名规则，如: 'Sum_Money'
- 对数据完全不做处理，比如一个数字类型，空的时候会有 0 和 null 两种情况
- 返回的数据需要前端计算处理, 十个字段有五个是要计算的
- 常常修改字段名
因为这些问题已经和后端激烈沟通过两次，无果。以数据量大，节省服务器资源等理由搪塞，我感觉就是纯偷懒。
所以想集思广益，我明天准备进行第三次沟通。
就查个表干脆数据库放开来让我自己查得了!
第 1 条附言 · 2023-03-23 12:23:45 +08:00
补充一下，本该分页的 table ，硬是不分页。 根据 sort 排序，也不排，就得前端排。
我的意思也不是说这些都是麻烦大事儿，可能很多这种小细节造成我的不满~
我的意思也不是说这些都是麻烦大事儿，可能很多这种小细节造成我的不满~
 |
1
a62527776a 2023-03-23 11:30:34 +08:00
摸一摸得了 领导都无所谓
|
 |
2
westoy 2023-03-23 11:37:30 +08:00
搞不好， 你只要碰过， 后端出了点什么问题都是你的锅
搞的好， 后端裁掉， 给你涨薪 15% ，你一个人干一个组的活儿 好吧， 开始选择吧 |
 |
3
miv 2023-03-23 11:40:45 +08:00 via Android
就是提前沟通好约定好格式啊，再干活呀。
|
 |
4
urnoob 2023-03-23 11:42:15 +08:00
除了 常常修改字段名 其他都好说
如果因为 常常修改字段名 出了什么事故 这个可以怼 |
 |
5
hhjswf 2023-03-23 11:43:41 +08:00 via Android  5
为什么一定要 restful ？
|
 |
6
en20 2023-03-23 11:45:51 +08:00
向上反馈,不解决就拒绝联调. 如果这都解决不了说明管理有极大问题,趁早跑路
|
 |
7
Ninja365 2023-03-23 11:46:30 +08:00
规范问题就不要太较真了，费时费力，这帮懒鬼还不会听你的，尽量向上级寻求帮助，一定要卡住接口文档且不要随意变更，这是前后端对接规范，同时这种事还是要靠自己花费经历去游说和维护，没办法
|
 |
8
wu00 2023-03-23 11:49:17 +08:00 1
1 ，不遵循 restful 风格很正常，大部分遵循 restful 的也都是不伦不类的，还不如全 post 用起来省心
2 ，这个该喷 3 ，0 是 0 ，null 是 null ，没毛病，文档上说清楚就行 4 ，这个得看场景吧，有些就是需要前端处理 /计算，以满足不同的展现形式，前端也有部分前端逻辑吧，不可能所有地方都是只管拿到数据绑定就行了。 5 ，“常常”修改是不是填第 2 点的坑呢 |
 |
9
lsymy OP |
|
10
lsymy OP |
 |
11
ivvei 2023-03-23 11:57:17 +08:00 1
也就 5 算个问题，其他都是屁大点事
|
 |
12
haoswil 2023-03-23 12:02:38 +08:00
1. 你有话语权就就摁住给老子改
2. 你没话语权，功能，功能，功能，功能满足就行，管你是什么💩山，你在坐在💩上面，和💩差不多恶心 |
 |
13
8355 2023-03-23 12:03:09 +08:00
有矛盾上升啊 跟你领导说 让你领导找他领导咯
别急啊 如果领导不在乎就这样好了 有 bug 让测试提给后端 |
|
14
hhjswf 2023-03-23 12:06:41 +08:00 via Android
@lsymy 干过后端你肯定知道，屎山代码数据库乱七八糟 null ，0 都有，要么前端处理要么后端处理，看谁老实人拗不过了
|
 |
15
bhbhxy 2023-03-23 12:17:33 +08:00
我公司的后端完全就是在混，返回的字段名称居然是
{ "count(*)": 10 } 纬度给返回 100 ，也不管对不对 接口通不通完全不管，连鼠标点一点都不做，上线了事，bug 全都要前端去反馈，自己从来不测 找领导反馈，领导和稀泥，说不理解我们为什么不能好好沟通 现在明白了，碰上烂人烂事真没办法，只能避开 |
 |
19
chaleaochexist 2023-03-23 12:32:43 +08:00
这样啊.
那我可能会前后端一起做了. 把那个后端架空. 他就慌了. |
 |
20
sadfQED2 2023-03-23 12:37:45 +08:00 via Android
@ivvei 赞同，也就 5 算个问题，其他的都屁大点事。处理 0 null 都是基本操作，百度地图的 api 有时候都数字文本轮流来，只要后端是 php ，都这德行
|
|
21
bhbhxy 2023-03-23 13:10:25 +08:00
@lsymy 工作态度不行，工作能力不行，有一次我用 ES6 的语法提交数据：
const data = { user, score } 他接口写得有问题，看了我的前端代码以后，居然说我提交的格式不对，反问我知不知道 JSON 语法， 非得用传统方法写一遍验证是他的问题才肯去改，水平烂又迷之自信，笑死了 |
 |
22
waytodelay 2023-03-23 14:13:40 +08:00
对数据完全不做处理，比如一个数字类型，空的时候会有 0 和 null 两种情况
不知道楼主做的什么业务，金融项目下，0 和 null 不是划等号的 |
 |
23
wcao 2023-03-23 14:20:31 +08:00
恩，2-4 工作经验的时候，和楼主一样。
看见不爽的就想喷，想按照规范来，都想好好写代码。 不过现在嘛，除了第 5 个，会影响我划水，其他的都是小问题。 包括你补充的，table 不分页，前端排序，无所谓，我能排的，都可以放在前端。只要一次返回几 W 条数据接口不卡，用户不说体验问题。我才难得管。 写自己的项目不香吗，把你所有的规范都可以用到自己项目里。 |
 |
24
timedivision 2023-03-23 14:27:51 +08:00
分页都不分有点过分了
|
 |
25
vone 2023-03-23 14:29:58 +08:00 1
数字返回 null 就受不了？
我们公司系统接口的 json 格式，在数值类型有值时返回字符串格式，如“123”，值为 null 时直接给你返回“--”。 这才叫精彩。 |
 |
26
pengtdyd 2023-03-23 14:35:18 +08:00 1
《计算机世界里面的任何问题都可以通过加一层来解决》
|
 |
27
imgalaxy 2023-03-23 14:45:05 +08:00
{
... key: [null], ... } 来点我司的奇葩 |
 |
28
RealJacob 2023-03-23 15:12:53 +08:00
你说的很多都不复杂啊，感觉后端稍微一搞就可以
|
 |
29
opengps 2023-03-23 15:20:42 +08:00
如果不是从头做起，那么这个规范几乎没有任何意义，因为已经错过了为了规范而规范的时候了。花掉额外的成本去统一老项目，反而会让原本稳定的老项目变得很不稳定，风险代价远大于代码不规范带来的管理问题
|
 |
30
root01 2023-03-23 15:20:51 +08:00
能不能用？ 能用就行了，公司不自己开的
|
 |
31
fiypig 2023-03-23 15:31:12 +08:00
接口文档给你整好，其他负责做就好，做好划水就对了。
|
 |
32
la2la 2023-03-23 16:14:32 +08:00
如果没有规范的管理，前端最好关键数据字段都做异常处理，不管后端给的数据标不标准，虽然很麻烦但是可以避免很多坑
|
 |
33
zero47 2023-03-23 17:03:28 +08:00
前转后多年。
看到第一点我觉得 OP 有点矫情，但看到第二点我就支持 OP 去骂后端。关于 0 和 null 这个问题其实要看数据录入方，我做 Android 时都是要判空的，这也是后来为什么有 kotlin 这门语言。排序分页应该是后端的职责，而且能让前端自己实现的，后端做肯定也简单。计算这个确实就是看谁的话语权大，无伤大雅。 |
|
34
zero47 2023-03-23 17:08:45 +08:00
「节省服务器资源等理由搪塞」，这就更应该分页。
你也可以回怼什么都扔一大堆数据过来，前端占用大，会卡。 |
 |
35
GzhiYi 2023-03-23 17:10:06 +08:00
这情况 OP 最好弄一层 BFF 。
|
 |
36
ww940521 2023-03-23 17:39:55 +08:00
这种我以前还会吐槽下，现在都是能用就行，不能用再套层壳处理下，有什么大不了的。
|
 |
37
LeegoYih 2023-03-23 17:43:52 +08:00
我怀疑你在内涵企业微信的 OpenAPI
|
 |
39
SenLief 2023-03-23 17:54:00 +08:00
删改字段名都不通知的吗。。。
|
 |
40
linl1n 2023-03-23 17:54:05 +08:00
上 Typescript 能解决大部分 0 null "-" ""还有字段命名的问题，剩下的前端计算排序啥的佛系了，能写就写实在麻烦写就反馈上级
|
 |
42
simonCN 2023-03-23 18:56:32 +08:00
为啥要入前端啊，我发现前端人员普遍不懂计算机知识，如果不是很感兴趣建议早点转回后端。
|
 |
43
maocat 2023-03-23 19:01:10 +08:00
业务这东西，前端牛逼前端做，后端牛逼后端做
|
 |
44
muzuiget 2023-03-23 19:05:40 +08:00
自己加一层抽象不就完了，把外部的东西”标准化“后，再传入自己代码处理。
|
 |
45
opentrade 2023-03-23 19:21:33 +08:00 1
再过几年，你也不会在乎了
|
 |
46
lingo 2023-03-23 21:14:41 +08:00
3 和 5 不能接受。但是这都是能通过提前定好接口来解决了。谁不符合接口谁的锅。
其他的都是鸡毛蒜皮的。腾讯的接口都能一个 ID 给你三个名字。re 不 restful 无所谓了，有个标准都好说。前端要计算什么的太正常了。 |
 |
47
dqzcwxb 2023-03-23 22:07:55 +08:00 1
遵守 restful 比你剩下的几个要严重得多
|
 |
48
5h4nh 2023-03-23 22:49:27 +08:00
@westoy 建议选择「搞的好， 后端裁掉， 给你涨薪 15% ，你一个人干一个组的活儿」不用怕，如果你真的忙，老板不是瞎子，会招人帮你打下手的。
|
|
49
5h4nh 2023-03-23 22:58:05 +08:00
关于 2,5 楼主可以考虑弄一个 "gate"，例如这个库 https://github.com/typestack/class-transformer
一般的后端框架（ Java Sprint, Python FastAPI ）写 API 接口会定义请求的 Payload 的 Schema(一般就是写个 Class ），反过来想，前端也可以定义 Schema 给调 API 得到的 JSON ，不对就直接崩溃，是字段变了就直接找后端麻烦。 |
 |
50
gbin 2023-03-23 23:40:55 +08:00 via Android
你们后端需要 swagger design first
https://swagger.io/blog/api-design/design-first-or-code-first-api-development/ |
 |
51
darkengine 2023-03-24 00:29:50 +08:00
create_at, created_at, creat_at, create_time 同一个项目的不同接口 😂
|
 |
52
pubby 2023-03-24 08:55:43 +08:00 via iPhone
|
 |
53
MEIerer 2023-03-24 09:20:18 +08:00
是的，后端垃圾前端会不好受，但返过来就没啥事
|
 |
54
weiwoxinyou 2023-03-24 09:42:54 +08:00
@MEIerer #18 但是前端垃圾用户会不好受
|
 |
56
oppoic 2023-03-24 09:53:31 +08:00
这个东西靠自觉，你沟通一次不行，后续再沟通也不可能行
即便这次来回拉扯行了，新接口又不按规矩来，你能怎么办？ 技术方面好的方案就是好的，能掰扯的不多，正常你指出一个问题，后端应该抱着感谢的态度才对，大家集思广益把东西做好 |
 |
57
liuky 2023-03-24 09:55:17 +08:00 1
需求天天改, 员工天天换, 你指望能有多规范哦, 规则是死的人是活的, 程序能跑就行, 屎山你改了出问题了你的责任, 屎改好了不出问题系统运行稳定你就可以走了, 用不上你了
|
 |
59
op351 2023-03-24 10:12:29 +08:00
前端直接调数据库坑也很大 没有一个成熟的 orm 系统
graphql 之类的用起来也很操蛋 |
 |
60
maxgorgorCopy 2023-03-24 10:23:00 +08:00
我自己做客户端 前端 服务端，1 2 3 4 点现在已经习惯了。看什么风格代码都没问题。至于第五点确实该骂后端
|
 |
61
orzorzorzorz 2023-03-24 10:48:21 +08:00 1
我刚毕业的时候，得蒙为我引路的老大厚爱，颇被器重。当时也是年轻气盛，碰见这情况不得呼天抢地求爷爷告奶奶地跟老大哭诉，晓之以理动之以情诱之以利：“操你妈的改不改，改不改？不改我就……”那时候老大只是笑笑不说话，也没为难我，只是不了了之了。
当我还在研究轮子，分享会也老是提改改改的方案的时候，老大提桶了，我坐上了老大的位置。 后来有一天，有个新人进来，他看见这一团糟的业务逻辑，对我说：“操你妈的改不改，改不改？不改我就……” 我当时也只能笑笑不说话，也没为难他，只是不了了之了。 只是在心里补了一句：“……就认了。” |
 |
62
cangcang 2023-03-24 10:51:00 +08:00
不规范无所谓，只要他永远别改
|
 |
63
28Sv0ngQfIE7Yloe 2023-03-24 10:55:46 +08:00
restFul 又不是银弹，为啥必须要用,,
|
 |
64
duan602728596 2023-03-24 12:46:47 +08:00
我这以前还见过直接把密码明文传回来的，喷了三个月才改。所以不要神化后端，有些人就是能力不行，只不过他恰好做后端而已。
|
 |
65
lovelylain 2023-03-24 13:41:38 +08:00 via Android
1. 无所谓，全 post 真香
2. 新增的对接时可以纠正，存量的不管 3. 新增的对接时可以纠正，存量的不管，建议用 protobuf 定义接口，字段标准而且不用另外维护文档 4. 看实际情况，如果后端接口并非专门针对你这个场景提供，那么前端计算合理 5. 不应该，类似 2 和 3 ，即使不合理也非必要不修改，前后端沟通好要解决 2 的问题除外 6. 如果分页和排序条件能和 DB 设计对应，就应该后台分页排序，对应不上本身后台也要全捞出来才能排序的话，可考虑前端做。 |
 |
66
xiaojun1994 2023-03-24 15:13:56 +08:00
后端返回结构都不统一，了解一下
|
 |
67
Yukiteru 2023-03-24 16:31:18 +08:00
这帖子里这么多嘲讽楼主的回复，怕不都是正好符合楼主描述的后端吧？
|
 |
68
yuningWang8 2023-03-24 17:08:22 +08:00
习惯就好了。有意见提一下可以，没必要激烈沟通。
另外有一个办法：把经常用的代码封装成组件。后端如果给的接口不一致，直接告诉他们必须保持一致，否则组件不接受就行了。 |
 |
71
eycode 2023-03-24 17:37:09 +08:00
有没有可能他们也想改，无力回天怎么改，流水的士兵，铁打的岗位，除了第 5 点外，其他真不算事。如果改了，之前的功能是不是也跟着改，后端规范一改，前端多少功能要改，你摸清楚了没有，不是你一句规范就规范的。项目前期没有规划好，扔锅给老板呗
|
 |
72
hefish 2023-03-24 17:47:01 +08:00
看起来你得把后端也一并写了。 工资只有一份啊。 去吧。
|
 |
73
huijiewei 2023-03-24 23:10:20 +08:00
要求不要一次提那么多
先一步一步走 首先变量命名统一了。。。 |
 |
74
ruoxie 2023-03-25 00:11:27 +08:00
没领导？
|
|
75
opentrade 2023-03-25 00:21:37 +08:00
我关了一个这样的 PR https://github.com/rustdesk/rustdesk/pull/3694
|
 |
76
solitude2 2023-03-25 05:03:10 +08:00 via Android
哎，刚入职的我也感觉这里那里不合理，但是大家不愿意或不想听。没有话语权，还是老老实实完成功能吧。改变不了的，选人或制度的问题
|
 |
77
lyonbrown4ddd 2023-03-25 08:31:21 +08:00
这种让前端手动分页加排序的后端 见一个骂一个
|
 |
78
Outshine 2023-03-25 17:22:03 +08:00
> 后端的接口不遵循 restful
虽然我写的 API 都是 restful 的，但是我感觉不是 restful 也无伤大雅，只要你们有自己的标准或者不要太凌乱（比如 `/getAllUsersList`） > 帕斯卡、下划线命名混用，在一个字段可以见到 2 种命名规则，如: `Sum_Money` 这个不太能忍。不过不知道你们同一个数据在不同 API 返回字段是不是一样的命名？比如用户的 `nickname` 在不同的 API 下都是 `nickname` ，而不会出现 `nick_name` 和 `nickName`。 > 对数据完全不做处理，比如一个数字类型，空的时候会有 0 和 null 两种情况 这个得分情况，有的数据确实必须得有 0 和 null ，但是有的数据不可能出现 null （比如用户的帖子数） > 返回的数据需要前端计算处理, 十个字段有五个是要计算的 这个我倾向于后端计算，如果前端计算的话，ios 、安卓、网页端啥的不都得各自写一遍计算代码？如果计算方式需要改的话，前两者还需要重新打包上架，而且每个端都需要改一次。 > 常常修改字段名 这个也不能忍 --- 整体来说，你这些点像极了微信的狗屎 API |
 |
79
fenglc 2023-03-31 09:37:28 +08:00
@opentrade 您当前访问的页面存在安全风险！
公安机关温馨提醒： 您访问的 http://web.rustdesk.com 该网站被大量用户举报，网站含有未经证实的信息，可能造成您的损失，建议谨慎访问！ |
|
80
opentrade 2023-03-31 09:53:03 +08:00
|
Select Language