手握诺奖得主的大厂们为何逃不过崩溃的下场【差评君】

UP主: 差评君 · 时长: 10:34 · 🔗 B站原视频

发布: 2024-01-29 · 收录: 2024-01-31

标签: 技术债 · 互联网大厂 · 行业分析 · 软件开发 · 降本增效

最近怎么老崩：连苹果都扛不住

差友们，我最近被崩溃整崩溃了。因为这段时间 App 崩得好像越来越频繁了：游戏打着打着强制下线，社区刷着刷着跳转 404，还有前段时间打不上车、各种奇奇怪怪的故障。

我最近年终总结，要不停互相传文件。听过无数次那个声音后，还是没传过去，又回来。

等等，这可是市值万亿的苹果，居然也会崩。我想可能是太久没关过机，那就重启再试试，结果还是不行。

我就想问一句：难道隔空投送这种常用功能也会崩？出了问题找 bug，发现 bug 找问题，这外行人都知道的道理，不至于置之不理吧？还真就不理。

仔细想想，大厂代码出事像家常便饭一样，bug 炸上天，老板也不管。这做派哪里像手握顶尖程序员的大厂，更像草台班子在演戏。难不成 App 崩背后有啥不为人知的秘密？

幕后黑手不是裁员：是技术债

大家好，我是差评君。这期我们聊聊 App 崩背后的黑手。

在“App 为什么会崩”这个问题上，开源节流、降本增效是一众评论里经常被提到的点。我一开始也挺赞同，因为“裁错人导致项目崩盘”的例子确实不少。

但我深挖之后发现，苹果也没裁员，甚至还是“不裁员”的好榜样，不一样崩吗？我梳理了近几年崩溃的各大案例，发现一只可怕的幕后黑手：技术债。

技术债指的是开发人员为了加速软件开发，在应该采用最佳方案时进行妥协，使用短期能加速开发的方案，从而在未来给自己带来额外的开发负担。

听起来抽象，下面用个故事讲清楚。

方轮车的故事：为了按时交付先凑合

事情是这样的：我们穿越到了一个全是外星人的星球，出行方式全是步行，连单车都没有。

我立马发现商机：造车。于是我拿着硬币雇了一群小山羊，分工合作：A 组做车架，B 组造轮子，C 组想办法让它动起来就行。

为了造势，我在星球上洒满广告，约定一周后造出一辆神奇的东西，坐在里面绕星球一圈。

但进展并不顺利：小山羊们不知道什么是轮子什么是车，动力方式想到的是让人去拉，甚至轮子阴差阳错弄成方的。眼看时间到了，退一步想，方轮子虽然拉起来费力气，但颠着颠着也能用，就先凑合着吧，有空再改。

这种凑合听起来奇葩，但在项目里，为了在极度压缩的时间下保证按时交付，这样的妥协很常见。

对当时的小山羊们来说，需求很简单：只要车能跑起来就好。就像一个 App 刚起步，不需要面对太复杂场景，能跑就行。但这时候也欠下了一笔承诺：未来要还的债。

技术债的“利息”：问题会越来越多

欠债不还，利息会压得你喘不过气。技术债也是一样。账单出来的时候，那鲜红的赤字让你无法逃避。

利息怎么体现在开发里？回到车的例子：我们就这么颠着出发，一开始平地还顺利，但到了崎岖路上，正方形车轮被卡住了。

怎么办？难道为了一个小障碍就让大家下车等着换轮子？牛都吹出去了，不能停，那就搭个板子，让车能过。这个方案确实快，但打板子这工作，其实就是在还“轮子设计”欠下的技术利息，而且每遇到问题就要缓一次。

如果程序像方轮车一样只有这点维护工作，还不至于让 App 无法修理。真正的问题在于技术债会迭代。

为了升级继续妥协：债越滚越大

产品总得不断升级。现在车大受欢迎，我们希望它跑快点。于是决定升级：装推进器。

听起来不错，无非更颠一点。颠不能忽视，所以这次升级不仅要解决速度，还得考虑稳定。

但换轮子？车正在跑，不可能让所有人都下来。硬加推进器又很颠，升级陷入两难。于是又一个奇葩决定诞生：把推进器做成斜向上的，让车稍微弹起，轮子不容易磕地，速度也提升。

虽然前进方式有点奇特，但算是更快更稳了。

更新当然是好事，App 有问题不更新肯定没人用。但正是这次妥协，运行又会出现新问题：车不停弹跳，乘客在车里乱飞，就得加固定装置；下坡会腾空而起，就得下坡关推进器换人力；将来甚至得考虑给方轮子修专属公路。

一次次妥协中，我们忙得不可开交，但围绕妥协形成的问题非但没减少，反而越来越多，技术债又加了一层。一层层叠下去，很难想象不崩是什么奇迹。

奇葩设计真的会发生：把“命中判定”塞给玩家电脑

有人会问：方轮子这么奇葩的设计真的会诞生吗？真的会。

比如某“3 亿鼠标的梦想”，因为服务器算力不足，就把“枪有没有打中”的计算放到玩家电脑上，服务器只拿数据做整合，导致但凡有玩家卡，这局游戏就会很鬼畜。

更离谱的是后来甚至把伤害值也放到玩家电脑上，相当于让玩家下来自己推车。算力问题是解决了，但玩家说了算的数据给外挂留足了空间，导致这款游戏从诞生开始就饱受外挂的迫害和羞辱。

我们一次次用不寻常的方法让程序跑起来，甚至已经无法意识到未来会发生什么。

技术债最可怕的是“朦胧感”：你以为更好，其实越陷越深

这还不是最可怕的地方。最可怕的是技术债的朦胧感：它不像真正的债务，你能清楚知道自己负债；它是潜移默化中突然出现，让你身负巨债。

因为相比拖着行李走路，坐在颠簸的车里更舒服；相比人力去拉不合理的推进器，又是更好的选择。注意力总在一次次“更好”上。

其实换轮子的呼声一直都在，但每次行驶危机出现时，多快好省的优化都比停车换轮子的代价小得多。除非有一天技术债迭代到所有优化都行不通，才会去想换轮子。

但换轮子就意味着重构，重新造一个新 App，代价太大了。甚至别说重构，这一堆奇葩 buff 叠一起，拧颗螺丝都得累个半死。在行驶的车上修车，本来就是不可能的选项。

真实案例：年薪百万，两个月只写了几行代码

这听起来夸张，但在程序员身上时时刻刻都在发生。

我在论坛刷到一个叫“偶尔盖”的经历。他曾是一名 Oracle 程序员，年薪近百万，但整整两个月就写了几行代码。

入职前主管告诉他：我们的代码非常优秀，现在有一个小错误需要修复。他入职后很自信地拿到代码尝试运行，还津津有味地读了起来。

很快他发现一个问题：代码读不懂。因为代码里填满各种废话，几十层嵌套随处可见，一些神秘标志没有任何解释；不仅废话连篇，还乱定义规则，神秘的“宏”像家常便饭一样，能写满整张屏幕。

想拉个人问问更是天方夜谭，因为这套代码过手的人不计其数。就算找到作者，经过时间洗礼，大概率看到自己以前写的东西也得骂一句：这啥玩意儿啊。

可问题是读不懂怎么办？明明是个小 bug，死活修不好。说重构又丢人，但代码有 2500 万行，只能硬看。

两周过去，他只找到 20 个相关的标志，至于有什么用，他也不知道。意识到无法正常解决后，他开始暴走：什么代码规范、什么准则都不要了，有错误就硬改。

他举了个例子：他想写一句“人吃饭要用筷子”，系统报错，因为美国人、英国人、俄罗斯人吃饭用勺子不用筷子；他改成“除了这些人吃饭都用筷子”，系统又报错，因为印度人既不用筷子也不用勺子；他再改，系统又报错；他以为已经足够合理时，总有一个 bug 出来给他一巴掌。

年薪百万，每天工作就是写废话，而且要写好几个月，直到错误消失。甚至仅仅想写一句“人吃饭要用筷子”，都得写无数测试，让它适应庞大的代码。

偶尔盖的遭遇，其实是大佬们普遍的现象。这时候再谈能不能重构已经没意义了，因为代价太大：抛开现有用户和市场资源不说，光是开发一个新 App 的人力成本就高得吓人。

回到崩溃事件：草台班子背后是历史决策的叠加

所以技术债浮出水面后，也就不难理解为什么会有这些离谱事件频频出现：693 亿、8719 万、第一司机成为亿万富翁、大型疑惑篇之“我的审核在海里”、游戏崩溃之“十脸懵逼”。

这些事好像坐实了“世界是个大草台班子”，甚至那句玩笑话：认识清华北大不如胆子大。

但这句玩笑折射出的是另一个世界：回头看，世界经历过无数变革，需求和外部环境一直变化，而过去的决策在当时就定死了。我们当然可以评判当时的决策多荒谬，但你现在嘲笑的，可能是当时人人赞叹的绝妙方案。

放眼未来，这宛如迷宫的时代该何去何从，没人能下定论。每个决策都像在变化的迷宫里找出路，下一个路口是通向终点的大道，还是注定错误的技术陷阱，我们一样迷茫。

结尾：代码如此，世界亦是如此

所以回到 App，一次次技术迭代不崩，似乎真的是一种奇迹。代码如此，世界亦是如此。

总有人感叹这个世界为什么运转得如此儿戏，但世界也只不过是由无数个债务产生的、史山代码拼凑的巨大系统。我们只能尽可能做出最好的选择，并为未来可能出现的问题做好准备。至于对错，就交给时间。

这里是差评君，今天就到这。如果你觉得不错，欢迎一键三连；有什么想说的，也欢迎在评论区互动。也可以关注我们的公众号“差评”，我们下次再见。