服务端开发错了，客户端就应该错着适配

V2EX = way to explore

V2EX 是一个关于分享和探索的地方

现在注册

已注册用户请登录

前情提要

我们的产品今日在开发环境暴露出一个风险，某些数据取值取不到了导致产品崩溃。

排查了半天数据和逻辑之后，发现是因为某个接口返回的数据新加了一种类型，但是这种类型的定义和之前的另一种类型是相同的，导致代码合并后，有的数据处理认为是之前的类型，有的认为是之后的类型，导致某些判断分支没有达成，最后导致数据没有正确解析。

问题简述

我们排查了问题之后，理了一下现在的逻辑。

假设我们之前的数据有 A ，B ，C 三种类型，然后根据数据的 type 字段等于 A ，B ，C 来判断数据类型，再根据类型去做相应的数据解析和操作。

但是现在服务端只在某些接口中，把 C 类型给区分成了 C 类型和 D 类型。C 类型的 type 字段是 C ，D 类型的 type 字段是 D 。但是现在的 D 类型的数值是我们之前客户端用的 C 类型，现在的 C 类型则是之前我们客户端会过滤掉的一种数据。老的接口中依旧只有 type 值为 C 。

于是我们现在如果需要在老的接口判断是否是我们需要的类型，就要经历下面几个判断才能确定值的类型。

这个数据来自新接口还是老接口
如果是老接口，那他的 type 是否等于 C
如果 type 等于 C ，他是否具有 data 字段
如果具有 data 字段，他的 data 字段下是否具有 sub_type 字段
如果具有 sub_type 字段，sub_type 字段是否等于 1
如果等于 1 ，那他就是我们之前用的老的 C 类型
如果等于 2 ，那他就是我们之前要过滤掉的类型

争议

理清逻辑后，我就去找服务端理论，为什么要设计成这样。

讨论了半天，总之就是服务端那边不同的人代码逻辑没有统一，最后导致类型定义不统一。

但是服务端表示我们不会改，因为改了容易出问题，而且 Web 端已经适配了，希望我们也适配一下。

我便问他: “但是你这逻辑已经错了，不处理一下吗？我们要适配你们的错误逻辑吗？”

服务端表示: “服务端写错了你们就错着适配吧。”

第 1 条附言 · 29 天前

我们公司的Web前端也是真的龟。

已经发现了很多类似的接口逻辑了。然后Web端真的就错着兼容。比如A数据里面里面包含E字段，E字段包含F字段，结果有的接口E字段里的F是空的，然后又在A里面包含了一个F，然后Web前端就这么兼容着做。然后服务端就以Web已经兼容了为理由所以不改。我都怀疑这些Web前端是不是都是托服务端关系走后门进的公司，怎么就服务端写什么接口都给兼容。

接口文档？不存在的，接口文档就是服务端把数据JSON往yapi里一导，心情好写点注释上去，你在文档里看不出这个字段可能会传什么值，也不明白这些值都有什么用途，你甚至都不知道这些字段是不是必填。

至于Leader，公司上面就一个老板，老板天天就忙活自己的事情，不参与这种技术上的讨论。

反正这一波我是要抗议的，凭什么你们服务端代码逻辑有问题要我们客户端给你擦屁股。

60 条回复 • 2024-10-24 18:40:44 +08:00

zcf0508

29 天前 via Android

找 leader ，一级一级往上找

jydeng

29 天前

直接拉群，闹起来

lai9fox95

29 天前

错了不改这是什么逻辑，这种情况一旦出现了大概率还会有下一次，不想给自己堆屎山挖坑就要坚决一点

sagaxu

29 天前

先出接口文档，后写代码

1. 有效减少此类错误
2. 发生这种错误时不用扯皮

Helsing

29 天前 via iPhone

这种肯定是服务端适配，向上提升吧，不要惯着他们

falcon05

29 天前 via iPhone

如果有一个 bug ，其他功能都依赖这个 bug ，那它不是一个 bug ，而是一个 feature 。估计后端系统已经严重依赖这个错误了，就会像这样。

Forestar

29 天前

先把 pm 拉进来，说不通再把你们的 leader 拉进来，还说不通再把对面的 leader 拉进来，这总说的通了吧

PainAndLove

29 天前

先扯皮，服务端不认，再拉 leader 。让 leader 决策

adoal

29 天前

做一个 v2 版的接口，你们调用 v2 ，其它调用 v1 的可以以后迁移。
注：v2 不是指 V2EX 的意思。

Yanlongli

29 天前

大概是新增的类型替换了之前被废弃的类型，然后出现的兼容问题

wolfie

29 天前 via Android

这是管理问题，需求评审时就得评估的，找你客户端负责人去对线就行。

ugpu

29 天前

@adoal 赞.
1. 提出了解决方案
2. 解决了争端大家都不尴尬
OP 一定要当着很多人面说出来解决方案当着 leader 的面大家都好做.

zypy333

29 天前

倾向于趁早发现趁早改，除非实改动的影响跟成本实在无法负担

cowcomic

29 天前

是谁的问题和这个问题谁改是两件事情

是谁的问题是个定性判断，就你说的这个情况，肯定是后端的问题，已经上线接口的定义怎么能轻易修改，这部分向上反馈要的是公道和后续的处理整改

至于这个问题谁改这个事儿，道理上也应该是后台改，但实际上是成本的考量，谁改成本最低，这个成本包括但不限于（开发成本，测试成本，投入的时间造成的机会成本，团队教育的成本，等等）不同的人看到的不一样，这块就让你们领导去 PK 吧

zsc8917zsc

29 天前

对于历史功能的改动，可以考虑向下兼容或者强制更新。
向下兼容就对接口做好版本号管理，指定版本号调用指定版本号的接口。
不想向下兼容就强制更新，天下太平。

lyxxxh2

29 天前

"而且 Web 端已经适配了"
那得先将 web 改了,得考虑下时间成本,让有老大决定吧。

不过话说回来:
我认为产品崩溃不是类型问题,是沟通上的。
1. 这种特殊情况,api 文档不标个备注?

2. "如果是老接口，那他的 type 是否等于 C... " 逻辑就太冗余了,没那么复杂啊。
拦截处理就行。
例如 js:
```
r1 = Promise.resolve({c:1}) # 老接口重写类型
.then(v => {v.c = 'b'; return v}).then(v => console.log(v.c))

r2 = ... # 新接口不管
```

Yukineko

29 天前

客户端更新要审核发版，服务端随时都可以更新，怎么可能让客户端适配。。

qq135449773

29 天前

这种问题一般都是 leader 无能+敷衍工作导致的

yiqiao

29 天前

客户端改不是要发版本吗？那用户用老版本不是还是会造成奔溃吗
服务端这么硬气啊？不算 KPI 的？

9136347

29 天前

以文档为准，文档写的什么是什么，谁对不上找谁。

dishuibaby

29 天前

我们的 app 的绝大多数 bug ，不管客户端、服务端的问题。只要服务端能兼容的，优先服务端处理，保证用户服务

janus77

29 天前

要改也不能默默改，不光要跟平级同事对质清楚，还要跟上级聊清楚，根本上来说到底是谁的责任。
不然事情过后淡忘了，后面他们就以讹传讹认为是你的错误了，职场里面太多这种事了，不得不防

zhtyytg

29 天前

@janus77 太对了

guanzhangzhang

29 天前

先给领导讲，有了大体意见后再拉群和拉产品 pm ，有记录再看怎么做

horizon

29 天前

这一般不都是客户端做的事吗？怎么反过来了

RandomJoke

29 天前

哪那么复杂，加个新的 type 字段不就行了...回到问题，崩溃不应该，你可以报错，但不能崩溃，解决这个问题最快的方案就是你们先适配，因为本身你们崩溃不管怎样都是要处理的，需要一次发版

slert

29 天前

记得以前接口文档字段有拼写错误也只能捏着鼻子按照拼错的做
问题抛给领导，他说怎么搞就怎么搞，虽然按错的方式做事很难受，但如果大家都不在乎，也就随便吧

wuzhewuyou

29 天前

一般都改服务端啊，客户端（除 web ）改了还要重新分发

bigscotaleha

29 天前

客户端不需要发版本，审核成本的吗？

ala2008

29 天前

不兼容的接口能上线？没有升级版本的客户端怎么办

guanhui07

29 天前

一般都服务端做兼容。。所以服务端也可能要给客户端抹屁股

debuggeeker

29 天前

你就问他一句：是不是你服务端升级之后，才把客户端搞死的！

james2013

29 天前 via Android

不改，只有客户端搞错了，服务端兼容
要不然，影响众多客户端用户

lasuar

29 天前

找 leader ，没有懂技术的 leader 那就莫得法了。

xloger

28 天前

"然后 Web 端真的就错着兼容"，因为他们没强类型...

我之前一公司，后端给我 JSON ，他连 Array 和 Object 都分不清，Map 和 Array 也分不清。一个字段不存在，薛定谔地返回：null 、""、[]、"null"。

mouyase

28 天前

@xloger #35

你别说，你还真别说，我之前就吐槽过服务端反的数据千奇百怪

https://v2ex.com/t/1004262

prosgtsr

28 天前 via iPhone

当然是后端改啦，客户端就算发版本老版本用户怎么办

IvanLi127

28 天前

你得问问 web 前端有啥意见，做白工是一回事，服务端改好了他那会不会崩又是一回事。

看你们这流程……明显就是后端定接口，所以他们说了算。这时候他们不提供文档，你得提供文档要求他们，达成共识才能往下推进，不然这种事没默契只能一直扯。

但是，客户端是存在多个版本同时在线的，如果不能热更新，不可能随随便便一个服务端能解决的 bug 让客户端发版呀。遇到这种事谁解决的速度快成本低，谁解决。

yhnbgfd

28 天前

两个问题, 1 错误的东西要不要改, 我建议改, 放任不管只会加速奔溃的到来. 2 谁兼容谁, 天大地大客户端最大, 服务端你多牛逼能让所有客户端同时更新到最新版?

kandaakihito

28 天前

看笑了，这种破事我待过的项目组里面也发生过，最后基本就是谁软了谁改。

cnoder

28 天前

一般有问题都是服务器兼容吧，客户端要发版啊，怎么可能随发随改

vipfts

28 天前

谁工资高听谁的, 谁工资高谁干活

securityCoding

28 天前

你们的 app 没啥人用吧....这后台这么犟种要是在我们组下一秒就得拉总监进来了~

Anarchy

28 天前 via Android

只有服务端给客户端擦屁股的情况啊，客户端强制升级成本很大的。

fregie

28 天前

看对错没有意义，看成本和风险（当前的和未来的）

Foxkeh

28 天前

屎山就是这么来的

dudubaba

28 天前

前端确实龟，不然也不会处于鄙视链最底层了

hefish

28 天前

完全不用的，只要来 v2 发帖，声讨相关开发，错误就会自动修复的。

ugpu

28 天前

前端: 后端写的啥玩意没统一天天折腾人知道写代码嘛？
后端: 说一万遍你还是个贴图仔！数据结构业务需求你不懂！照着刷新显示就行了！有些事你不懂, 历史遗留问题在那里！

建议: 全栈(干)

tyrantZhao

28 天前

不应该是评估下修改带来的风险么？

Ghostisbored

28 天前

我们前端后端都是商量着来的怎么方便怎么来要不工作还干不干下去了

zyzweb

28 天前 via iPhone

@slert 拼错的没办法只能将错就错

xuld

28 天前

成年人不能执着于讲道理。
当年日本鬼子说丢了个士兵就要进攻，他和你讲道理了吗？
永远记住：真理只在导弹射程中。

在中国公司里面，老板就是道理，技术不是，你更不是。

从客观看，后端承认了错误、前端兼容了错误、而你不愿兼容。

如果你兼容了，一定程度上会让代码变得更难维护，但你赢得了“容易合作”的荣誉。

如果你坚持让后端改了，甚至让前端也改，那你就是修复了一个错误，同时你得罪了两个开发。

关键看你的领导是个什么类型的人物。

如果你的领导是个知人善用的类型，他会鼓励你坚持自己的底线，这样错误才会纠正，才利于公司长期发展。

如果你的领导是个有控制欲、图稳类型，他会觉得你破坏了团队和谐，给你打上“不愿配合”、“不好管理”的标签，并加速对你的清理，这样公司剩下的都是碌碌无为的庸才。

如果你明确分析了不同选择带来的后果，自然知道自己应该怎么做。

总之，不同的选择会有不同的结果，事在人为

xuanbg

28 天前

关键在于这是一个历史包袱啊，不是后端一开始就做错了。后端肯定不会去改的，改成对的万一出点意想不到的问题，他接不住。换我也是不肯改的。代码就在那，你们谁要改都可以，反正我不接。

chase196

28 天前

兄弟这题我会
认同 53 楼 @xuld 的观点，相信他也是一位睿智的职场前辈

假设你们的产品是一个超高并发、容不得半毫差错的产品，通常情况服务端业务上线需要中断服务，客户端更改影响的只是界面显示。发现紧急 BUG ，客户端可以兼容处理，前端第一时间发补丁解决用户当前问题，流程没有问题。

至于你说的设计、实现问题，接口如何统一、什么时候改，是解决问题后优化的事情，此时你可以发挥个人魅力，在公司影响或者主导把这个事情漂亮完成，并且让老板知道

相信这样的事情一次或者多次之后，下次来抗议的可能要换服务端了