V2EX = way to explore
V2EX 是一个关于分享和探索的地方
现在注册
已注册用户请  登录
mouyase
V2EX  ›  程序员

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

  •  
  •   mouyase ·
    mouyase · 13 天前 · 5729 次点击

    前情提要

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

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

    问题简述

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

    假设我们之前的数据有 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 条附言  ·  13 天前

    我们公司的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
        1
    zcf0508  
       13 天前 via Android   ❤️ 1
    找 leader ,一级一级往上找
    jydeng
        2
    jydeng  
       13 天前
    直接拉群,闹起来
    lai9fox95
        3
    lai9fox95  
       13 天前
    错了不改这是什么逻辑,这种情况一旦出现了大概率还会有下一次,不想给自己堆屎山挖坑就要坚决一点
    sagaxu
        4
    sagaxu  
       13 天前   ❤️ 2
    先出接口文档,后写代码

    1. 有效减少此类错误
    2. 发生这种错误时不用扯皮
    Helsing
        5
    Helsing  
       13 天前 via iPhone
    这种肯定是服务端适配,向上提升吧,不要惯着他们
    falcon05
        6
    falcon05  
       13 天前 via iPhone   ❤️ 2
    如果有一个 bug ,其他功能都依赖这个 bug ,那它不是一个 bug ,而是一个 feature 。估计后端系统已经严重依赖这个错误了,就会像这样。
    Forestar
        7
    Forestar  
       13 天前
    先把 pm 拉进来,说不通再把你们的 leader 拉进来,还说不通再把对面的 leader 拉进来,这总说的通了吧
    PainAndLove
        8
    PainAndLove  
       13 天前
    先扯皮,服务端不认,再拉 leader 。 让 leader 决策
    adoal
        9
    adoal  
       13 天前   ❤️ 7
    做一个 v2 版的接口,你们调用 v2 ,其它调用 v1 的可以以后迁移。
    注:v2 不是指 V2EX 的意思。
    Yanlongli
        10
    Yanlongli  
       13 天前
    大概是新增的类型替换了之前被废弃的类型,然后出现的兼容问题
    wolfie
        11
    wolfie  
       13 天前 via Android
    这是管理问题,需求评审时就得评估的,找你客户端负责人去对线就行。
    ugpu
        12
    ugpu  
       13 天前
    @adoal 赞.
    1. 提出了解决方案
    2. 解决了争端 大家都不尴尬
    OP 一定要当着很多人面说出来解决方案 当着 leader 的面 大家都好做.
    zypy333
        13
    zypy333  
       13 天前
    倾向于趁早发现趁早改,除非实改动的影响跟成本实在无法负担
    cowcomic
        14
    cowcomic  
       13 天前   ❤️ 1
    是谁的问题和这个问题谁改是两件事情

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

    至于这个问题谁改这个事儿,道理上也应该是后台改,但实际上是成本的考量,谁改成本最低,这个成本包括但不限于(开发成本,测试成本,投入的时间造成的机会成本,团队教育的成本,等等)不同的人看到的不一样,这块就让你们领导去 PK 吧
    zsc8917zsc
        15
    zsc8917zsc  
       13 天前
    对于历史功能的改动,可以考虑向下兼容或者强制更新。
    向下兼容就对接口做好版本号管理,指定版本号调用指定版本号的接口。
    不想向下兼容就强制更新,天下太平。
    lyxxxh2
        16
    lyxxxh2  
       13 天前
    "而且 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
        17
    Yukineko  
       13 天前
    客户端更新要审核发版,服务端随时都可以更新,怎么可能让客户端适配。。
    qq135449773
        18
    qq135449773  
       13 天前
    这种问题一般都是 leader 无能+敷衍工作导致的
    yiqiao
        19
    yiqiao  
       13 天前
    客户端改不是要发版本吗?那用户用老版本不是还是会造成奔溃吗
    服务端这么硬气啊?不算 KPI 的?
    9136347
        20
    9136347  
       13 天前
    以文档为准,文档写的什么是什么,谁对不上找谁。
    dishuibaby
        21
    dishuibaby  
       13 天前
    我们的 app 的绝大多数 bug ,不管客户端、服务端的问题。只要服务端能兼容的,优先服务端处理,保证用户服务
    janus77
        22
    janus77  
       13 天前   ❤️ 1
    要改也不能默默改,不光要跟平级同事对质清楚,还要跟上级聊清楚,根本上来说到底是谁的责任。
    不然事情过后淡忘了,后面他们就以讹传讹认为是你的错误了,职场里面太多这种事了,不得不防
    zhtyytg
        23
    zhtyytg  
       13 天前
    @janus77 太对了
    guanzhangzhang
        24
    guanzhangzhang  
       13 天前
    先给领导讲,有了大体意见后再拉群和拉产品 pm ,有记录再看怎么做
    horizon
        25
    horizon  
       13 天前
    这一般不都是客户端做的事吗?怎么反过来了
    RandomJoke
        26
    RandomJoke  
       13 天前
    哪那么复杂,加个新的 type 字段不就行了...回到问题,崩溃不应该,你可以报错,但不能崩溃,解决这个问题最快的方案就是你们先适配,因为本身你们崩溃不管怎样都是要处理的,需要一次发版
    slert
        27
    slert  
       13 天前
    记得以前接口文档字段有拼写错误也只能捏着鼻子按照拼错的做
    问题抛给领导,他说怎么搞就怎么搞,虽然按错的方式做事很难受,但如果大家都不在乎,也就随便吧
    wuzhewuyou
        28
    wuzhewuyou  
       13 天前
    一般都改服务端啊,客户端(除 web )改了还要重新分发
    bigscotaleha
        29
    bigscotaleha  
       13 天前
    客户端不需要发版本,审核成本的吗?
    ala2008
        30
    ala2008  
       13 天前
    不兼容的接口能上线?没有升级版本的客户端怎么办
    guanhui07
        31
    guanhui07  
       13 天前
    一般都服务端做兼容。。所以服务端也可能要给客户端抹屁股
    debuggeeker
        32
    debuggeeker  
       13 天前
    你就问他一句:是不是你服务端升级之后,才把客户端搞死的!
    james2013
        33
    james2013  
       13 天前 via Android   ❤️ 1
    不改,只有客户端搞错了,服务端兼容
    要不然,影响众多客户端用户
    lasuar
        34
    lasuar  
       13 天前
    找 leader ,没有懂技术的 leader 那就莫得法了。
    xloger
        35
    xloger  
       13 天前
    "然后 Web 端真的就错着兼容",因为他们没强类型...

    我之前一公司,后端给我 JSON ,他连 Array 和 Object 都分不清,Map 和 Array 也分不清。一个字段不存在,薛定谔地返回:null 、""、[]、"null"。
    mouyase
        36
    mouyase  
    OP
       13 天前
    @xloger #35

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

    https://v2ex.com/t/1004262
    prosgtsr
        37
    prosgtsr  
       13 天前 via iPhone
    当然是后端改啦,客户端就算发版本老版本用户怎么办
    IvanLi127
        38
    IvanLi127  
       13 天前
    你得问问 web 前端有啥意见,做白工是一回事,服务端改好了他那会不会崩又是一回事。

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

    但是,客户端是存在多个版本同时在线的,如果不能热更新,不可能随随便便一个服务端能解决的 bug 让客户端发版呀。遇到这种事谁解决的速度快成本低,谁解决。
    yhnbgfd
        39
    yhnbgfd  
       13 天前
    两个问题, 1 错误的东西要不要改, 我建议改, 放任不管只会加速奔溃的到来. 2 谁兼容谁, 天大地大客户端最大, 服务端你多牛逼能让所有客户端同时更新到最新版?
    kandaakihito
        40
    kandaakihito  
       13 天前
    看笑了,这种破事我待过的项目组里面也发生过,最后基本就是谁软了谁改。
    cnoder
        41
    cnoder  
       13 天前
    一般有问题都是服务器兼容吧,客户端要发版啊,怎么可能随发随改
    vipfts
        42
    vipfts  
       13 天前
    谁工资高听谁的, 谁工资高谁干活
    securityCoding
        43
    securityCoding  
       13 天前
    你们的 app 没啥人用吧....这后台这么犟种要是在我们组下一秒就得拉总监进来了~
    Anarchy
        44
    Anarchy  
       13 天前 via Android
    只有服务端给客户端擦屁股的情况啊,客户端强制升级成本很大的。
    fregie
        45
    fregie  
       13 天前
    看对错没有意义,看成本和风险(当前的和未来的)
    Foxkeh
        46
    Foxkeh  
       13 天前
    屎山就是这么来的
    dudubaba
        47
    dudubaba  
       13 天前
    前端确实龟,不然也不会处于鄙视链最底层了
    hefish
        48
    hefish  
       13 天前
    完全不用的,只要来 v2 发帖,声讨相关开发, 错误就会自动修复的。
    ugpu
        49
    ugpu  
       13 天前
    前端: 后端写的啥玩意 没统一 天天折腾人 知道写代码嘛?
    后端: 说一万遍你还是个贴图仔! 数据结构 业务需求你不懂!照着刷新显示就行了! 有些事你不懂, 历史遗留问题在那里!

    建议: 全栈(干)
    tyrantZhao
        50
    tyrantZhao  
       13 天前
    不应该是评估下修改带来的风险么?
    Ghostisbored
        51
    Ghostisbored  
       13 天前
    我们前端后端都是商量着来的 怎么方便怎么来 要不工作还干不干下去了
    zyzweb
        52
    zyzweb  
       12 天前 via iPhone
    @slert 拼错的没办法只能将错就错
    xuld
        53
    xuld  
       12 天前
    成年人不能执着于讲道理。
    当年日本鬼子说丢了个士兵就要进攻,他和你讲道理了吗?
    永远记住:真理只在导弹射程中。

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

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

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

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

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

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

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

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

    总之,不同的选择会有不同的结果,事在人为
    xuanbg
        54
    xuanbg  
       12 天前
    关键在于这是一个历史包袱啊,不是后端一开始就做错了。后端肯定不会去改的,改成对的万一出点意想不到的问题,他接不住。换我也是不肯改的。代码就在那,你们谁要改都可以,反正我不接。
    chase196
        55
    chase196  
       12 天前
    兄弟这题我会
    认同 53 楼 @xuld 的观点,相信他也是一位睿智的职场前辈

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

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

    相信这样的事情一次或者多次之后,下次来抗议的可能要换服务端了
    spritecn
        56
    spritecn  
       12 天前
    改了,其他适配方怎么办,新开个接口不失为好的方案,但要协调好成本及进度问题
    falcon05
        57
    falcon05  
       12 天前 via iPhone
    @xuld 典型的犬儒主义,太过油腻。现实中不喜欢这种人,网络上选择 block 。
    LazYFire
        58
    LazYFire  
       12 天前
    歪个楼,求问大公司里是不是很少出现这种情况。
    hugedeffing
        59
    hugedeffing  
       12 天前
    @LazYFire 感觉还是有的。不过都是发现第一时间反馈自己老大,找上后端老大,让后端他们自己解决。这边帮忙定位错误就已经给面子了。后面就是老大们去扯皮了,自己只要保留链路证据就行,闹到 ceo 那边都不关我们的事情。即便改也是我们为了帮你们这个 bug 适配修改,且后续出问题不背锅
    sampeng
        60
    sampeng  
       12 天前
    这玩意在无论大小公司都不是谁在理听水的,而是谁拳头大听谁的
    关于   ·   帮助文档   ·   博客   ·   API   ·   FAQ   ·   实用小工具   ·   2935 人在线   最高记录 6679   ·     Select Language
    创意工作者们的社区
    World is powered by solitude
    VERSION: 3.9.8.5 · 37ms · UTC 14:52 · PVG 22:52 · LAX 06:52 · JFK 09:52
    Developed with CodeLauncher
    ♥ Do have faith in what you're doing.