理性讨论工作里前端和后端到底是怎样配合的

[RexCarryu]

工作里经常遇到明明接口字段可以直接复用，但每次后端都会在接口新增字段并以不方便修改，升级麻烦，数据持久化，代码已经合了等各种借口搪塞过去。 这样的做法导致前端为了一个新增字段多了很多循环和组装数据的代码。想问下这种情况在前端工作中真的很常见吗。 我对前端的认知是请求接口组装数据，循环等类似代码越少越好，能复用就复用这样性能才会更佳。 是不是我太自私了，工作里应该更多配合后端工作啊。恳请大家指点迷津

[codehz]

这就是为啥要有个 graphql

[ufbek]

mark 一下.
感觉上还要以后端为准, 后端肯定也需要考虑前端的字段.
可能"借口"并不是借口, 就是实际情况...

[estk]

反正老板用了有问题全找前端，他不管什么服务器宕机或者后端突然把 int 改成 string 这种事，反正他看到的就是前端有问题

[jsq2627]

很有可能是后端在维护一座💩山，旧的字段能不碰就不碰

[shui14]

接口字段，字段 code 。万年圣战，这东西只需要在团队里公开讨论一下，约束好就可以了，至于前端还是后端处理这叫事情吗？
一般而言，
业务导向的，如内容展示或者常规后台系统，线性业务，后台数据层可以直接筛选，看能不能协调，前端不是 ts 流行定义一下字段结构，遴选一下
技术导向的，如时序数据医疗影像网络拓扑地理空间分析等等，这个开发本身就是个交叉的活，原始数据更好，甚至最好自己 decode ，同样约定好就行

[StateMa]

’ 我对前端的认知是请求接口组装数据，循环等类似代码越少越好，能复用就复用这样性能才会更佳。‘我也是这样想的。🤣

[Moierby]

为了不在扯皮中处于下风，我这两年自学后端，甚至有时候指导后端写代码

[xubeiyan]

我司的某个后端设计 API 还能 {"flyAreaData1”: “…”，“flyAreaData2”: “…”}，不过我已经懒得喷他了

[jones2000]

后台给数据，前端拼装，很正常， 一个接口一个数据转换函数。往上垒。维护和改动影响最小。 如果要复用， 那要做完整的测试用例了， 否则改了一个底层一个复用的地方， 没有完整的测试用例跑一遍， 谁知道会在哪里地方就报错了。

[weeei]

后端肯定是以数据库表结构好维护的原则来开发和设计的。
前端就是干业务、写面条代码，说不定下个版本这字段有没用了。
在这种环境下，需要一个中间层干脏活。
你们公司小、人少，人员流动性又高的话，该下班下班。

[perfectlife]

看人下饭，配合中也讲人情事故吧

[beijinglowb]

互相理解，后端和 DBA 也是同样的扯皮，有时增减一个字段也不是他能定的。比如我们在日本维护一个 2 千多个表的屎山，一次 sql 查询几十个表，所有字段都要严格按照设计书来做。一般来说前端的职责是尽量去做兼容，js 也是所有语言里兼容面最广的，设计初衷就是如此。

[leroy20317]

我们公司也有 接口 {label1: '', label2: '', label3: ''}表示标签列表 前端拿到还要整合数据

[hooych]

原有接口更新，新功能用新字段，防止一个字段多个用法造成维护困难；
新增接口，含义相同用现有接口相同字段，其他的用新字段；
公共字段定义后不再改变，按需添加新字段。

[HyperionX]

如果这个接口只给你一个页面用，一般都不会这么新增。
但是后端经常面对一个接口三个端用或者前端 10 个页面都在用，每个端还要分叉逻辑。整一个新版本接口，老接口下线极度困难，常年有老接口明知已经没有端在用了还是持续有流量，怎么下线？额外付出的人力物力远不如加一个字段简单。
可以多从别人立场思考问题，除了少数个例一般不会胡诌蒙你，都一起合作了基本的信任还是要有多。

[HyperionX]

讲道理我工作中遇到的前端基本都是抢着写逻辑，常年说你不好弄我来就行写个循环的事儿。都不知道网上咋能撕起来的，到底是哪些群体在互喷

[MoYi123]

一般要讲性能前, 请先做 benchmark.

[sadfQED2]

@HyperionX +1

我是后端。但是我和前端对接一般都是“你看这个好处理不，不好处理我这里帮你处理了”。工作这么多年都是大家商量着来，谁简单就放谁那里处理。哪来那么多撕逼互喷啊

[xuhai951753]

看谁背锅 如果你不背锅 屎山就屎山了
保留讨论记录，免得扯皮
大部分情况下前端还是弱势的，而且性能不会因为几个字段就差了

[Desiree]

没文档，最好不要对接接口