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

[mouyase]

前情提要

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

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

问题简述

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

假设我们之前的数据有 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 端已经适配了，希望我们也适配一下。

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

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

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

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

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

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

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

[zcf0508]

找 leader ，一级一级往上找

[jydeng]

直接拉群，闹起来

[lai9fox95]

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

[sagaxu]

先出接口文档，后写代码

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

[Helsing]

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

[falcon05]

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

[Forestar]

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

[PainAndLove]

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

[adoal]

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

[Yanlongli]

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

[wolfie]

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

[ugpu]

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

[zypy333]

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

[cowcomic]

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

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

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

[zsc8917zsc]

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

[lyxxxh2]

"而且 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]

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

[qq135449773]

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

[yiqiao]

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

[9136347]

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

[dishuibaby]

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

[janus77]

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

[zhtyytg]

@janus77 太对了

[guanzhangzhang]

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

[horizon]

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

[RandomJoke]

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

[slert]

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

[wuzhewuyou]

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

[bigscotaleha]

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

[ala2008]

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

[guanhui07]

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

[debuggeeker]

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

[james2013]

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

[lasuar]

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

[xloger]

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

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

[mouyase]

@xloger #35

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

https://v2ex.com/t/1004262

[prosgtsr]

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

[IvanLi127]

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

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

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

[yhnbgfd]

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

[kandaakihito]

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

[cnoder]

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

[vipfts]

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

[securityCoding]

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

[Anarchy]

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

[fregie]

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

[Foxkeh]

屎山就是这么来的

[dudubaba]

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

[hefish]

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

[ugpu]

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

建议: 全栈(干)

[tyrantZhao]

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

[Ghostisbored]

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

[zyzweb]

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

[xuld]

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

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

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

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

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

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

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

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

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

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

[xuanbg]

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

[chase196]

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

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

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

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

[spritecn]

改了,其他适配方怎么办,新开个接口不失为好的方案,但要协调好成本及进度问题

[falcon05]

@xuld 典型的犬儒主义，太过油腻。现实中不喜欢这种人，网络上选择 block 。

[LazYFire]

歪个楼，求问大公司里是不是很少出现这种情况。

[hugedeffing]

@LazYFire 感觉还是有的。不过都是发现第一时间反馈自己老大，找上后端老大，让后端他们自己解决。这边帮忙定位错误就已经给面子了。后面就是老大们去扯皮了，自己只要保留链路证据就行，闹到 ceo 那边都不关我们的事情。即便改也是我们为了帮你们这个 bug 适配修改，且后续出问题不背锅

[sampeng]

这玩意在无论大小公司都不是谁在理听水的，而是谁拳头大听谁的