这是一个创建于 508 天前的主题，其中的信息可能已经有所发展或是发生改变。
工作里经常遇到明明接口字段可以直接复用，但每次后端都会在接口新增字段并以不方便修改，升级麻烦，数据持久化，代码已经合了等各种借口搪塞过去。 这样的做法导致前端为了一个新增字段多了很多循环和组装数据的代码。想问下这种情况在前端工作中真的很常见吗。 我对前端的认知是请求接口组装数据，循环等类似代码越少越好，能复用就复用这样性能才会更佳。 是不是我太自私了，工作里应该更多配合后端工作啊。恳请大家指点迷津
第 1 条附言 · 2023-07-14 10:30:28 +08:00
感谢各位巨佬回复，让我对前端角色在团队里的职责更加清晰，只有前后端互相理解才能达到最高效
 |
1
codehz 2023-07-13 18:48:54 +08:00
这就是为啥要有个 graphql
|
 |
2
ufbek 2023-07-13 19:56:02 +08:00
mark 一下.
感觉上还要以后端为准, 后端肯定也需要考虑前端的字段. 可能"借口"并不是借口, 就是实际情况... |
 |
3
estk 2023-07-13 20:30:15 +08:00 via iPhone
反正老板用了有问题全找前端，他不管什么服务器宕机或者后端突然把 int 改成 string 这种事，反正他看到的就是前端有问题
|
 |
4
jsq2627 2023-07-13 20:59:54 +08:00  1
很有可能是后端在维护一座💩山，旧的字段能不碰就不碰
|
 |
5
shui14 2023-07-13 21:01:27 +08:00
接口字段，字段 code 。万年圣战，这东西只需要在团队里公开讨论一下，约束好就可以了，至于前端还是后端处理这叫事情吗？
一般而言， 业务导向的，如内容展示或者常规后台系统，线性业务，后台数据层可以直接筛选，看能不能协调，前端不是 ts 流行定义一下字段结构，遴选一下 技术导向的，如时序数据医疗影像网络拓扑地理空间分析等等，这个开发本身就是个交叉的活，原始数据更好，甚至最好自己 decode ，同样约定好就行 |
 |
6
StateMa 2023-07-13 21:48:18 +08:00
’ 我对前端的认知是请求接口组装数据，循环等类似代码越少越好，能复用就复用这样性能才会更佳。‘我也是这样想的。🤣
|
 |
7
Moierby 2023-07-13 21:57:07 +08:00 2
为了不在扯皮中处于下风，我这两年自学后端，甚至有时候指导后端写代码
|
 |
8
xubeiyan 2023-07-13 22:05:03 +08:00 via Android
我司的某个后端设计 API 还能 {"flyAreaData1”: “…”，“flyAreaData2”: “…”}，不过我已经懒得喷他了
|
 |
9
jones2000 2023-07-13 23:20:38 +08:00
后台给数据，前端拼装，很正常， 一个接口一个数据转换函数。往上垒。维护和改动影响最小。 如果要复用， 那要做完整的测试用例了， 否则改了一个底层一个复用的地方， 没有完整的测试用例跑一遍， 谁知道会在哪里地方就报错了。
|
 |
10
weeei 2023-07-13 23:39:32 +08:00
后端肯定是以数据库表结构好维护的原则来开发和设计的。
前端就是干业务、写面条代码，说不定下个版本这字段有没用了。 在这种环境下，需要一个中间层干脏活。 你们公司小、人少，人员流动性又高的话，该下班下班。 |
 |
11
perfectlife 2023-07-14 00:17:08 +08:00
看人下饭，配合中也讲人情事故吧
|
 |
12
beijinglowb 2023-07-14 08:26:13 +08:00 via iPhone
互相理解，后端和 DBA 也是同样的扯皮，有时增减一个字段也不是他能定的。比如我们在日本维护一个 2 千多个表的屎山，一次 sql 查询几十个表，所有字段都要严格按照设计书来做。一般来说前端的职责是尽量去做兼容，js 也是所有语言里兼容面最广的，设计初衷就是如此。
|
 |
13
leroy20317 2023-07-14 09:12:51 +08:00
我们公司也有 接口 {label1: '', label2: '', label3: ''}表示标签列表 前端拿到还要整合数据
|
 |
14
hooych 2023-07-14 09:31:12 +08:00
原有接口更新，新功能用新字段，防止一个字段多个用法造成维护困难；
新增接口，含义相同用现有接口相同字段，其他的用新字段； 公共字段定义后不再改变，按需添加新字段。 |
 |
15
HyperionX 2023-07-14 10:04:41 +08:00
如果这个接口只给你一个页面用，一般都不会这么新增。
但是后端经常面对一个接口三个端用或者前端 10 个页面都在用，每个端还要分叉逻辑。整一个新版本接口，老接口下线极度困难，常年有老接口明知已经没有端在用了还是持续有流量，怎么下线？额外付出的人力物力远不如加一个字段简单。 可以多从别人立场思考问题，除了少数个例一般不会胡诌蒙你，都一起合作了基本的信任还是要有多。 |
|
16
HyperionX 2023-07-14 10:06:32 +08:00 1
讲道理我工作中遇到的前端基本都是抢着写逻辑，常年说你不好弄我来就行写个循环的事儿。都不知道网上咋能撕起来的，到底是哪些群体在互喷
|
 |
17
MoYi123 2023-07-14 10:12:08 +08:00
一般要讲性能前, 请先做 benchmark.
|
 |
18
sadfQED2 2023-07-14 10:13:14 +08:00 via Android 5
|
 |
19
xuhai951753 2023-07-14 10:19:13 +08:00
看谁背锅 如果你不背锅 屎山就屎山了
保留讨论记录，免得扯皮 大部分情况下前端还是弱势的，而且性能不会因为几个字段就差了 |
 |
20
Desiree 2023-07-14 10:24:03 +08:00
没文档，最好不要对接接口
|
 |
21
RexCarryu OP 感谢各位巨佬回复，工作里还是多互相理解吧
|
 |
22
8355 2023-07-14 11:15:22 +08:00
说实话符合我之前对部分前端的理解，有的前端就是最好只输出啥都不做，改一点都要后端适配。
有些就是啥都能做，可协商互相不搞屎山。 有些 app 有历史版本问题，可能大改版之后要 v1/v2 拆分可以理解这个没办法就是不能动。。 但是 web 就。。。。 |
 |
23
Rache1 2023-07-14 11:19:44 +08:00
有些前端恨不得后端把数据全做了，甚至返回格式都能完美适配他用的那些乱七八糟的组件，拿到后直接 setState 就跑起来🤷♂️，连个数据转换都写不好
|
 |
25
spicy777 2023-07-14 14:03:09 +08:00
都是商量着来，哪边方便就那边弄
|
 |
26
murmur 2023-07-14 14:05:52 +08:00
有啥麻烦的，多定义点 Map<Object, Object>就搞定了
|
 |
27
rm0gang0rf 2023-07-14 14:06:00 +08:00
说实话昂, 还没有工地盖楼的师傅们默契, 人家不玩花活儿 不任性
|
 |
28
mtjgu 2023-07-14 14:10:39 +08:00
@Rache1 数据处理和转换的过程抽象为独立的步骤，可以实现数据变更时的灵活性。当数据源发生变化时，只需要专注于更新数据清洗的规则和转换逻辑，而不需要修改前端代码。这样可以提高系统的可维护性和扩展性，并减少前后端耦合度，这样降低开发和维护成本。
|
 |
29
CHTuring 2023-07-14 14:15:19 +08:00
有没有见过权限字段用 xxx1 xxx2 xxx3 xxx4 来表示的，只能说无奇不有 😊
|
 |
30
Zenon 2023-07-14 14:24:53 +08:00
前端后端都是我，我说了算 🙉
|
 |
31
wednesdayco 2023-07-14 14:37:17 +08:00
我见过一个接口返回{"py":xxx,"pingyin":xxx,"pinying":xxx,"pinyin":xxx,"pinying":xxx},这个 xxx 都是一个数据[doge]
|
Select Language