​“ 故意埋一个坑，在你验收的时候并不会触发；而触发的时候你根本懵逼到想不到是他。

我指的并不是淘宝325事件的程序员，而是我的亲身经历。”

淘宝325事件

了解淘宝325事件的小伙伴们可以跳过本节了。

3月25日，淘宝App打开之后，会出现一个告警弹窗，苹果手机才有。如下图（图片在微博上搜的，出处看水印）：

许多人自然而然的卸载了淘宝App，然后重新安装。

但是弹窗警告依然存在；从一开始的需要手动关闭，变成了闪一下就消失。

关于此事的谣言，大概是：

某iOS开发绩效被打了3.25分，

据说，3.25分意味着没有年终奖，

意味着请你走人；

可能是iOS开发不服，

便埋了一个bug，

就是那个弹窗警告。

事件发生后，

接盘的开发人员第一时间并没有找到彻底的解决方案，

可能只是找到了弹窗如何存在的代码，

没有找到唤起弹窗的代码，

所以只能让弹窗闪一下就消失；

直到3月25日下午16:01，

淘宝在微博辟谣，

让大家更新到最新版；

但并没有解释来龙去脉。

这个谣言的截图太长了，本文就不贴了，想看的话，很容易找到。

淘宝325事件个人分析（并不重要）

1. 这件事情对淘宝并没有产生什么正面效应，所以不是官方运营策划。如果非要硬凹是为了特价版上线，那策划的不漂亮呀。而且并没有看到继续加大热度。

2. 这是个人或者小团体设计、计划的，不论是谁设计好的，iOS开发得去实现它。所以，这事儿得从iOS开发查起。

有的朋友并没有安装最新版淘宝，就等着看3月28日会发生什么呢；好奇宝宝们27号晚上别睡，熬到凌晨看看？

一念成魔的故事

我为什么倾向于相信这是程序员的恶作剧？

因为我亲身经历，知道程序员有这个能量。

2018年初，乙方移交项目给我们，包括源代码。

我，就是那个苦主。

当时我刚刚到岗，研发团队还没有组建，光杆司令一杆。

但是，项目必须在短时间内接下来！

后端我可以自己啃，但是手机端实在没有经验，接不下来；匆忙中找了一个iOS兼职小姐姐，这个小姐姐接了一周，表示不做了，于是我们又找了一个iOS兼职小哥哥。

（小姐姐会在后面闪回时出场，请不要着急忘了她。）

这个项目在2017年8月（注意这个时间点）初步验收过一次；之后由于商务问题，乙方的研发便基本停滞了。

在2018年初接手的时候，我们发现iOS端调用我们的H5，打开系统相册的时候便卡住了，无法返回上一步，无法去到下一步，只能从后台杀死App。

我们的小哥哥每天啃代码，不觉得哪里有问题。

找乙方的开发和经理讨论，对方只说 “原来是好的，你们是不是哪里改错了”，问的多了，便说 “这个就是iOS开发的能力了”；反正这个功能以前是好的，你们接手后不好了，你们开发不行。

继续硬着头皮撸代码，查资料。

从iOS代码开始，排查到H5代码。

用各种浏览器、在各种平台测试。

甚至怀疑到我们用的开发框架上，给人家提bug，人家拿出证据说框架好好的。

只有我们的产品不行！

每次开会，提到iOS相册问题，都没有进展。

两个月过去了，各项工作都步入正轨，七七八八的问题都修好了，唯独这个问题还在那里。

小哥哥说很奇怪，跟的很深了，也没发现问题。后台日志也没有crash，也没有什么报警；日志里什么信息都没有。

“ 姐，我也请教了其他牛人，也没查出问题，他们说重构一下也许能解决问题。”

“ 姐，估计只能重构了。这两个月App的逻辑我都捋清楚了，重构的话功能方面我都清楚。”

重构即是推到重来，预估两个月，费用市场价。

我也没有更好的办法，但我想解决问题，跟老板申请，老板同意了。

重构到中期，看到了胜利的曙光。

看官先上眼代码吧：

看到那个嚣张的函数命名了吗? 再看里面的实现，你会发现函数命名所代表的含义还谦虚了呢！我亲自搜索了一下， 这段代码的意思是：

如果项目打包的时候，目标iOS版本包含了iOS11，就把唤起相册时界面上所有按钮的文字设为空！

文字设为空以后，按钮的宽度就无穷小了。

所以问题并不是界面卡住了，不是不能前进不能后退，而是前进后退的按钮无穷小，你看不见！随意瞎点都点不到。

品品，你都不用细品。这个功能 “原来好好的”，因为原来的iOS开发（我后面叫他Trick哥，他是乙方的兼职开发）打包的时候（2017年8月左右），iOS11还没有正式发布！

iOS11在2017年9月底正式发布，我们接手后，虽然 “什么都没改”，但是打包时自然会包含iOS11，问题自然而然就出现了！

呵！呵！

如果当时再年轻5岁，我一定把证据甩到所有人都在的群里，先把他脸打了解气！

但是我没有，当时距离交接已经半年了，老板跟我一致觉得，我们就只管走好自己的路吧。

乙方经理成熟稳重，知道底线。

最大的可能是兼职的Trick哥，担心一锤子买卖结束后，自己后面没活了，所以自己给自己铺铺路？

要么就是Trick哥和乙方有矛盾纠纷，故意使坏？ 

不管什么原因，我们接手后跟他请教，他肯定不能说有这个坑。唯一快速解决方案是我们还找他继续开发，他假模假样的解决一个遗留bug。

一个后续

事情解决后的半年，我与小哥哥一起吃了个饭。他提到，最开始接手的小姐姐（接了一周不做了的小姐姐）在他接手的时候警告他、劝他别碰，因为代码 “一碰就是坑”。但是小哥哥很自信， “偏向虎山行” 。没想到最后真的差点没搞定虎山。 

他建议我重构不仅仅是为了解决bug，而是代码不重构别人读不下去，他自己都快要放弃了。

又一个后续

写这篇文章的时候，我又翻了一下聊天记录（因为我工作偏管理岗，许多工作沟通都在微信中，所以只要不换工作，聊天记录我都不删），发现了一个新疑点：

那个bug文件最后更改日期是2018年1月29日；看下图。

我们一开始拿到的代码编译运行都成问题，几番沟通后，对方在1月30日发了新代码包给我们；看下图。

细思极恐，也许Trick哥不知道要交接给甲方，以为是乙方不要他了所以有脾气了？

突然很想让对方查查他们的GIT提交历史。

苦主想说的话

程序员这个行业，程序员与程序员之间的差距，不知其几千里也。

我是个什么事情都想做好的人。

刚毕业初入职场被分配了模块解bug，就把bug系统里所有遗留的bug都翻出来解了，包括那种放了两三年没人看的bug。

后来开始做新功能开发，曾经收到过客户的表扬信。

后来带团队做一个升级项目，我已经离职半年了，前交付经理还把产品顺利上线的祝贺邮件发到我私人邮箱。

后来业务线解散，我又被发配去做开发，测试小朋友一听说分到了我做的功能，直接就说 “那我就不测了” ，虽然这样做不对，但还是很高兴自己做的东西有了点 “品牌” 效应。

以我的智商程度，我能理解Trick哥这么做的原因或者目的；可是以我的单纯程度，实在不能理解：真的到了用这种手段的地步了吗？

君子爱财，可以取之无道吗？

前些天，微博上有个老师讲法律知识：假如小偷偷了你的东西，你追他，然后他跑着跑着掉进河里死了，那么你没有责任，因为追小偷是正当的。

但是，如果你追着追着，小偷掉进河里，向你求救，但是你不救，然后他死了。那么你要为自己的不作为负责任。而且偷东西也罪不至死。

所以，老师总结，有理往往会变成没理。

作为打工者，程序员或多或少会受到不公对待，最顺手最秘密的方式当然是在代码里做手脚。 可是无意中，自己从有理变成了没理，法律都不会保护你。

至于没有受到不公对待，为了个人利益而去做手脚的人，看见我的中指了吗？