我们的产品今日在开发环境暴露出一个风险,某些数据取值取不到了导致产品崩溃。
排查了半天数据和逻辑之后,发现是因为某个接口返回的数据新加了一种类型,但是这种类型的定义和之前的另一种类型是相同的,导致代码合并后,有的数据处理认为是之前的类型,有的认为是之后的类型,导致某些判断分支没有达成,最后导致数据没有正确解析。
我们排查了问题之后,理了一下现在的逻辑。
假设我们之前的数据有 A ,B ,C 三种类型,然后根据数据的 type 字段等于 A ,B ,C 来判断数据类型,再根据类型去做相应的数据解析和操作。
但是现在服务端只在某些接口中,把 C 类型给区分成了 C 类型和 D 类型。C 类型的 type 字段是 C ,D 类型的 type 字段是 D 。但是现在的 D 类型的数值是我们之前客户端用的 C 类型,现在的 C 类型则是之前我们客户端会过滤掉的一种数据。老的接口中依旧只有 type 值为 C 。
于是我们现在如果需要在老的接口判断是否是我们需要的类型,就要经历下面几个判断才能确定值的类型。
理清逻辑后,我就去找服务端理论,为什么要设计成这样。
讨论了半天,总之就是服务端那边不同的人代码逻辑没有统一,最后导致类型定义不统一。
但是服务端表示我们不会改,因为改了容易出问题,而且 Web 端已经适配了,希望我们也适配一下。
我便问他: “但是你这逻辑已经错了,不处理一下吗?我们要适配你们的错误逻辑吗?”
服务端表示: “服务端写错了你们就错着适配吧。”
我们公司的Web前端也是真的龟。
已经发现了很多类似的接口逻辑了。然后Web端真的就错着兼容。比如A数据里面里面包含E字段,E字段包含F字段,结果有的接口E字段里的F是空的,然后又在A里面包含了一个F,然后Web前端就这么兼容着做。然后服务端就以Web已经兼容了为理由所以不改。我都怀疑这些Web前端是不是都是托服务端关系走后门进的公司,怎么就服务端写什么接口都给兼容。
接口文档?不存在的,接口文档就是服务端把数据JSON往yapi里一导,心情好写点注释上去,你在文档里看不出这个字段可能会传什么值,也不明白这些值都有什么用途,你甚至都不知道这些字段是不是必填。
至于Leader,公司上面就一个老板,老板天天就忙活自己的事情,不参与这种技术上的讨论。
反正这一波我是要抗议的,凭什么你们服务端代码逻辑有问题要我们客户端给你擦屁股。
1
zcf0508 29 天前 via Android 1
找 leader ,一级一级往上找
|
2
jydeng 29 天前
直接拉群,闹起来
|
3
lai9fox95 29 天前
错了不改这是什么逻辑,这种情况一旦出现了大概率还会有下一次,不想给自己堆屎山挖坑就要坚决一点
|
4
sagaxu 29 天前 2
先出接口文档,后写代码
1. 有效减少此类错误 2. 发生这种错误时不用扯皮 |
5
Helsing 29 天前 via iPhone
这种肯定是服务端适配,向上提升吧,不要惯着他们
|
6
falcon05 29 天前 via iPhone 2
如果有一个 bug ,其他功能都依赖这个 bug ,那它不是一个 bug ,而是一个 feature 。估计后端系统已经严重依赖这个错误了,就会像这样。
|
7
Forestar 29 天前
先把 pm 拉进来,说不通再把你们的 leader 拉进来,还说不通再把对面的 leader 拉进来,这总说的通了吧
|
8
PainAndLove 29 天前
先扯皮,服务端不认,再拉 leader 。 让 leader 决策
|
9
adoal 29 天前 7
做一个 v2 版的接口,你们调用 v2 ,其它调用 v1 的可以以后迁移。
注:v2 不是指 V2EX 的意思。 |
10
Yanlongli 29 天前
大概是新增的类型替换了之前被废弃的类型,然后出现的兼容问题
|
11
wolfie 29 天前 via Android
这是管理问题,需求评审时就得评估的,找你客户端负责人去对线就行。
|
13
zypy333 29 天前
倾向于趁早发现趁早改,除非实改动的影响跟成本实在无法负担
|
14
cowcomic 29 天前 1
是谁的问题和这个问题谁改是两件事情
是谁的问题是个定性判断,就你说的这个情况,肯定是后端的问题,已经上线接口的定义怎么能轻易修改,这部分向上反馈要的是公道和后续的处理整改 至于这个问题谁改这个事儿,道理上也应该是后台改,但实际上是成本的考量,谁改成本最低,这个成本包括但不限于(开发成本,测试成本,投入的时间造成的机会成本,团队教育的成本,等等)不同的人看到的不一样,这块就让你们领导去 PK 吧 |
15
zsc8917zsc 29 天前
对于历史功能的改动,可以考虑向下兼容或者强制更新。
向下兼容就对接口做好版本号管理,指定版本号调用指定版本号的接口。 不想向下兼容就强制更新,天下太平。 |
16
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 = ... # 新接口不管 ``` |
17
Yukineko 29 天前
客户端更新要审核发版,服务端随时都可以更新,怎么可能让客户端适配。。
|
18
qq135449773 29 天前
这种问题一般都是 leader 无能+敷衍工作导致的
|
19
yiqiao 29 天前
客户端改不是要发版本吗?那用户用老版本不是还是会造成奔溃吗
服务端这么硬气啊?不算 KPI 的? |
20
9136347 29 天前
以文档为准,文档写的什么是什么,谁对不上找谁。
|
21
dishuibaby 29 天前
我们的 app 的绝大多数 bug ,不管客户端、服务端的问题。只要服务端能兼容的,优先服务端处理,保证用户服务
|
22
janus77 29 天前 1
要改也不能默默改,不光要跟平级同事对质清楚,还要跟上级聊清楚,根本上来说到底是谁的责任。
不然事情过后淡忘了,后面他们就以讹传讹认为是你的错误了,职场里面太多这种事了,不得不防 |
24
guanzhangzhang 29 天前
先给领导讲,有了大体意见后再拉群和拉产品 pm ,有记录再看怎么做
|
25
horizon 29 天前
这一般不都是客户端做的事吗?怎么反过来了
|
26
RandomJoke 29 天前
哪那么复杂,加个新的 type 字段不就行了...回到问题,崩溃不应该,你可以报错,但不能崩溃,解决这个问题最快的方案就是你们先适配,因为本身你们崩溃不管怎样都是要处理的,需要一次发版
|
27
slert 29 天前
记得以前接口文档字段有拼写错误也只能捏着鼻子按照拼错的做
问题抛给领导,他说怎么搞就怎么搞,虽然按错的方式做事很难受,但如果大家都不在乎,也就随便吧 |
28
wuzhewuyou 29 天前
一般都改服务端啊,客户端(除 web )改了还要重新分发
|
29
bigscotaleha 29 天前
客户端不需要发版本,审核成本的吗?
|
30
ala2008 29 天前
不兼容的接口能上线?没有升级版本的客户端怎么办
|
31
guanhui07 29 天前
一般都服务端做兼容。。所以服务端也可能要给客户端抹屁股
|
32
debuggeeker 29 天前
你就问他一句:是不是你服务端升级之后,才把客户端搞死的!
|
33
james2013 29 天前 via Android 1
不改,只有客户端搞错了,服务端兼容
要不然,影响众多客户端用户 |
34
lasuar 29 天前
找 leader ,没有懂技术的 leader 那就莫得法了。
|
35
xloger 28 天前
"然后 Web 端真的就错着兼容",因为他们没强类型...
我之前一公司,后端给我 JSON ,他连 Array 和 Object 都分不清,Map 和 Array 也分不清。一个字段不存在,薛定谔地返回:null 、""、[]、"null"。 |
36
mouyase OP |
37
prosgtsr 28 天前 via iPhone
当然是后端改啦,客户端就算发版本老版本用户怎么办
|
38
IvanLi127 28 天前
你得问问 web 前端有啥意见,做白工是一回事,服务端改好了他那会不会崩又是一回事。
看你们这流程……明显就是后端定接口,所以他们说了算。这时候他们不提供文档,你得提供文档要求他们,达成共识才能往下推进,不然这种事没默契只能一直扯。 但是,客户端是存在多个版本同时在线的,如果不能热更新,不可能随随便便一个服务端能解决的 bug 让客户端发版呀。遇到这种事谁解决的速度快成本低,谁解决。 |
39
yhnbgfd 28 天前
两个问题, 1 错误的东西要不要改, 我建议改, 放任不管只会加速奔溃的到来. 2 谁兼容谁, 天大地大客户端最大, 服务端你多牛逼能让所有客户端同时更新到最新版?
|
40
kandaakihito 28 天前
看笑了,这种破事我待过的项目组里面也发生过,最后基本就是谁软了谁改。
|
41
cnoder 28 天前
一般有问题都是服务器兼容吧,客户端要发版啊,怎么可能随发随改
|
42
vipfts 28 天前
谁工资高听谁的, 谁工资高谁干活
|
43
securityCoding 28 天前
你们的 app 没啥人用吧....这后台这么犟种要是在我们组下一秒就得拉总监进来了~
|
44
Anarchy 28 天前 via Android
只有服务端给客户端擦屁股的情况啊,客户端强制升级成本很大的。
|
45
fregie 28 天前
看对错没有意义,看成本和风险(当前的和未来的)
|
46
Foxkeh 28 天前
屎山就是这么来的
|
47
dudubaba 28 天前
|
48
hefish 28 天前
完全不用的,只要来 v2 发帖,声讨相关开发, 错误就会自动修复的。
|
49
ugpu 28 天前
前端: 后端写的啥玩意 没统一 天天折腾人 知道写代码嘛?
后端: 说一万遍你还是个贴图仔! 数据结构 业务需求你不懂!照着刷新显示就行了! 有些事你不懂, 历史遗留问题在那里! 建议: 全栈(干) |
50
tyrantZhao 28 天前
不应该是评估下修改带来的风险么?
|
51
Ghostisbored 28 天前
我们前端后端都是商量着来的 怎么方便怎么来 要不工作还干不干下去了
|
53
xuld 28 天前
成年人不能执着于讲道理。
当年日本鬼子说丢了个士兵就要进攻,他和你讲道理了吗? 永远记住:真理只在导弹射程中。 在中国公司里面,老板就是道理,技术不是,你更不是。 从客观看,后端承认了错误、前端兼容了错误、而你不愿兼容。 如果你兼容了,一定程度上会让代码变得更难维护,但你赢得了“容易合作”的荣誉。 如果你坚持让后端改了,甚至让前端也改,那你就是修复了一个错误,同时你得罪了两个开发。 关键看你的领导是个什么类型的人物。 如果你的领导是个知人善用的类型,他会鼓励你坚持自己的底线,这样错误才会纠正,才利于公司长期发展。 如果你的领导是个有控制欲、图稳类型,他会觉得你破坏了团队和谐,给你打上“不愿配合”、“不好管理”的标签,并加速对你的清理,这样公司剩下的都是碌碌无为的庸才。 如果你明确分析了不同选择带来的后果,自然知道自己应该怎么做。 总之,不同的选择会有不同的结果,事在人为 |
54
xuanbg 28 天前
关键在于这是一个历史包袱啊,不是后端一开始就做错了。后端肯定不会去改的,改成对的万一出点意想不到的问题,他接不住。换我也是不肯改的。代码就在那,你们谁要改都可以,反正我不接。
|
55
chase196 28 天前
兄弟这题我会
认同 53 楼 @xuld 的观点,相信他也是一位睿智的职场前辈 假设你们的产品是一个超高并发、容不得半毫差错的产品,通常情况服务端业务上线需要中断服务,客户端更改影响的只是界面显示。发现紧急 BUG ,客户端可以兼容处理,前端第一时间发补丁解决用户当前问题,流程没有问题。 至于你说的设计、实现问题,接口如何统一、什么时候改,是解决问题后优化的事情,此时你可以发挥个人魅力,在公司影响或者主导把这个事情漂亮完成,并且让老板知道 相信这样的事情一次或者多次之后,下次来抗议的可能要换服务端了 |
56
spritecn 28 天前
改了,其他适配方怎么办,新开个接口不失为好的方案,但要协调好成本及进度问题
|
58
LazYFire 28 天前
歪个楼,求问大公司里是不是很少出现这种情况。
|
59
hugedeffing 28 天前
@LazYFire 感觉还是有的。不过都是发现第一时间反馈自己老大,找上后端老大,让后端他们自己解决。这边帮忙定位错误就已经给面子了。后面就是老大们去扯皮了,自己只要保留链路证据就行,闹到 ceo 那边都不关我们的事情。即便改也是我们为了帮你们这个 bug 适配修改,且后续出问题不背锅
|
60
sampeng 27 天前
这玩意在无论大小公司都不是谁在理听水的,而是谁拳头大听谁的
|