前情提要
我们的产品今日在开发环境暴露出一个风险，某些数据取值取不到了导致产品崩溃。
排查了半天数据和逻辑之后，发现是因为某个接口返回的数据新加了一种类型，但是这种类型的定义和之前的另一种类型是相同的，导致代码合并后，有的数据处理认为是之前的类型，有的认为是之后的类型，导致某些判断分支没有达成，最后导致数据没有正确解析。
问题简述
我们排查了问题之后，理了一下现在的逻辑。
假设我们之前的数据有 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 端已经适配了，希望我们也适配一下。
我便问他: “但是你这逻辑已经错了，不处理一下吗？我们要适配你们的错误逻辑吗？”
服务端表示: “服务端写错了你们就错着适配吧。”

找 leader ，一级一级往上找

直接拉群，闹起来

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

先出接口文档，后写代码1. 有效减少此类错误2. 发生这种错误时不用扯皮

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

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

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

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

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

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

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

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

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

是谁的问题和这个问题谁改是两件事情是谁的问题是个定性判断，就你说的这个情况，肯定是后端的问题，已经上线接口的定义怎么能轻易修改，这部分向上反馈要的是公道和后续的处理整改至于这个问题谁改这个事儿，道理上也应该是后台改，但实际上是成本的考量，谁改成本最低，这个成本包括但不限于（开发成本，测试成本，投入的时间造成的机会成本，团队教育的成本，等等）不同的人看到的不一样，这块就让你们领导去 PK 吧

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

"而且 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 = ... ＃ 新接口不管

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

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

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

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

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

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

太对了

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

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

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

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

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

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

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

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

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