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