3 月 25 日凌晨，淘宝 iOS 客户端爆出了一个大 bug，用户启动 App 后会出现一个强制弹窗。
 

弹窗内容提示当前使用的是内测版，3 月 28 号后将无法继续使用。

注意，弹窗文案特意提到了「当地时间」。

也就是说，你把手机时间调成 28 号再进去，App 就会闪退，很多人已经验证过了。

显然，这是淘宝 App 团队犯了个错。
 

阿里人对「325」本来就很在意，这回估计更印象深刻了。
 

网上很多吃瓜群众开玩笑说，原来用了这么久的淘宝竟然是内测版。

还有人说，内测完毕了，买的东西是不是可以退钱了。

圈内人开玩笑的方式就更扎心直白了。

技术圈的人说，找产品经理。

产品圈的人说，找测试。

测试说，我啥也不知道。

因为好奇，估计平时不怎么上淘宝买东西的人也会打开淘宝 App 体验一下这个 bug，也算为 DAU 做贡献了。

当天上午 9 点 11 分，淘宝官方在微博上发表了一个声明来回应这次事故。

说实话，太没诚意了。

这个时间也是巧，难道是故意选的吗，哈哈！
 

这一哆嗦，伤害用户体验不说，也反映出了淘宝 App 团队的工作流程上的失误。

据说在内部被定义为 P1 级别的事故。
 

P 对应优先级，一般 P0 级别是最高，其次就是 P1 了，然后是 P2、P3 等。

很多公司都在用这套方法衡量问题紧急和重要度。

问题出现后，淘宝团队很快做出了调整，现在打开问题版本的淘宝 App 还是能看到那个弹窗，只不过是闪一下就关闭了。
 

而更新到最新版后，这个问题就解决了。

在 App Store 里看到更新提醒时（3 月 26 日），显示的时间是「2 天前」。

昨天出的问题在前天就已经提交了新版本？
 

莫非是内部早就知道？

还是说有时差？
 

咱也不懂，也不敢说。

这个 bug 到底是什么原因造成的呢？

我是 2011 年开始做 Android 和 iOS 开发的，做过的 App 也有十来款。
 

其实看到这个弹窗，立马让我想起了以前做技术时踩过的坑。

这就是一个把逻辑写死在 App 原生代码里产生的锅。
 

自己挖的坑，谁也怪不了！

原生 App 和 H5 不同，代码一旦打包就固定在那了，提交到 App Store 后是不能改的，除非再提交新版本覆盖老版本。

而 H5 和现在的一些混合开发技术，能在服务器更新代码后同步到前端，这样在不用发布新客户端版本的情况下也能实现更新。

通常把这种方法叫做 Hot Patch（热补丁或者热更新）。
 

比如微信 App 就是一个原生开发产物，而里面的公众号文章却是用 H5 实现的。

这也就是为什么没有更新微信版本时，能看到公众号的最新改变。

此外，产品运行的环境通常分测试环境和生产环境，有的还会有一个预发布环境。

测试环境就是和线上真实数据区分开的一套独立的服务器（A），供开发调试和测试使用。

对应的 App 版本是测试版（不对外）。

生产环境就是我们使用到的正式版本对应的线上真实数据服务器（B）。

对应的 App 版本是正式版（对外公开）。

开发完毕并经过严格测试后，工程师会将测试版 App 所对接的服务器从 A 修改为 B，然后打包成正式版。

也就是即将上线的版本。

这个过程可以理解为 App 有一个对外的插头，原本插在测试服务器 A 上，现在拔下来插到了正式的生产服务器 B 上。
 

在正式提交 App Store 之前，一般会先开启内部测试，也就是让公司内部人员或者测试用户提前安装新版本体验。

如果发现问题，就及时修正。

如果没有问题，则会正常提交到 App Store 进行审核。

一旦提交成功且发布，外部用户就会收到更新升级提醒。用户更新后，就会把最新版的代码安装在自己的手机上。

这次淘宝出的这个问题之所以无法在老版本里根治，就是因为代码写死在了 App 原生代码中。
 

另外，这个问题的触发就像一个倒计时的炸dan。
 

每次重新进入 App 时，代码会自动执行一个判断逻辑，如果当前系统时间和预设的时间正好吻合或者大于预设时间，就触发一个操作。

显然，在 28 号内测到期的前三天（25 号），这个逻辑被执行，操作被触发。

从 25 号凌晨开始，只要用户重新进入淘宝 App ，就会提示这个弹窗。
 

如果是在内部，这很正常。
 

坑就在于发布新版本时，把原本的内测版 App 当成正式版提交到 App Store 去了。
 

更坑的是，这么大的潜在风险逻辑，竟然还用代码写死在原生 App 里的方式实现。

轻前端、重后端、关键逻辑通过后端灵活控制不好么！
 

也就是说，这个问题版本其实已经早就随着某次更新安装到了用户的手机里。

除了这次更新，上一个版本是在一周前，再上个版本是在 3 周前。
 

如果按照测试发布节奏，隐藏 bug 的版本大概率是在前一周的发布里上线的。

时间一到，砰！

还有人会问了，为什么是每次重启 App 之后会弹窗呢？
 

因为每一个 App 启动时，从程序角度看就像进入一个大迷宫一样。

程序开始运行时，首先会进第一道门，然后四通八达通向各个功能模块和页面。

而这第一道门就是在 App 启动那一刻通过的，很多的版本检测代码和系统设置代码都会写在这里。

过了这道门，代码执行完，到其他模块就不会受到影响了。
 

并且，这道门只会通过一次。如果想再进一次，就得杀掉 App 进程再重启一次。

所以，每次重启淘宝 App，就会触发这个弹窗逻辑。

如果想完全解决这个问题，只能让用户更新到最新版本，以此覆盖老版本写死的代码。
 

昨天下午，淘宝官方又在微博上发了一条没诚意的内容。
 

认错就好好认，自己的锅自己背。

这么大的厂了，生娃还手忙脚乱，平时干啥去了！
 

一句「大家连接 WiFi，更新手机淘宝到最新版就好了」就完事了，还不忘宣传下自家要上的新产品。

没诚意。
 

写在最后

这个锅到底谁来背？
 

是产品经理设计的么？
 

是工程师故意写的么？

是测试人员开小差了么？

找到谁其实都没意义，大到团队协作下的开发和发布流程，小到逐行 code review，都值得反思。

作为吃瓜群众，希望看到的是淘宝官方对这次大范围事故有诚意的说明。

而不是开个玩笑就过了。
 

产品无小事、用户无小事、且行且珍惜！
 

··················END··················

你好，我是唐韧！前非著名程序员，现不知名产品人。
写过代码、做过产品、出过一本书，在创业公司厮杀过，也在大厂服役过，如今是一个自由职业者。
爱跑步、喜欢车、主要跟文字打交道，在这里记录自己想表达的一切！
 

作者：唐韧 
来源：唐韧公众号（ID：RyanTang007） 
个人微信：ryantangv
本文经授权发布，不代表51LA立场，如若转载请联系原作者。