对于bug 千万别想着永远消灭它

程序员和bug，就像是言情小说里的男女主角，上演着一次又一次的爱恨缠绵、相爱相杀。

年轻的程序员不信邪，总想法设法要永远的消灭它，结果却总是那么的一致：

为什么bug无法被完全消灭？追本溯源，bug到底是如何产生的呢？

一切，还得从一个奇葩的bug说起……

前几年，我曾经就职于一家游戏公司，我依稀还记得，坐我旁边的那哥们儿，写了一个让所有人至今难忘的bug。

时逢国庆节，运营部提来需求，要做一个充值打折的活动，国庆期间，充值任意金额，统统打八折，对！统统打八折！这波福利简单粗暴。

因为活动很简单，接任务的是我旁边那哥们儿，想也没想就开始埋头干起活儿来，鬼使神差，活动就在国庆前夕上线了。

功能开发后的结果是，玩家充值100元，系统给了等价于80元的钻石，游戏被骂惨了……

活动当天，那哥们儿和运营，统统接到了老板疯狂的骚扰电话。

代码没错吧，需求也没错吧，可玩家眼中的bug，就这么产生了。

当然，也免不了那该死的，不断变更的需求。

有一天，老板说要造一辆类似兰博基尼的跑车，要高仿！开完会，顺手丢了一张设计图给我。

第一个月，老板觉得跑车太low了，底盘太低，坑坑洼洼的地儿会磨蹭，损坏车辆，于是我抬高了跑车的底盘。

第二个月，产品看了看刚完工的跑车，“不行！这样设计，抓地力太差，轮胎必须换抓地力强的！”

老板看了样板车，觉得很棒，于是让我给客户试试，做个调研。

第三个月，“很棒的设计，如果能水陆两栖，就更好了，这样我连买船的钱都省了”

第四个月，我申请更多的研发经费，老板说：尽量在不增加成本的前提下，做得更好。于是我拿了点帆布和木头，改装了这辆跑车。做了测试，还不错，至少实现了水陆两栖的功能需求。

第五个月，拿给客户看，“能不能加装帆？这样船可以借助风力，省很多汽油。”

于是一辆越野性能极佳、可以水陆两栖，成本控制良好的兰博基尼被制造了出来：

春节回家，亲戚问我，你是搞什么的？想起那辆战船版兰博基尼，我毫不犹豫的说道：“搞bug的。”

3

有时候，bug的产生，程序员们真得背锅。

2015年，新浪微博曾经出现一个十分神奇的bug，一名用户，想注册昵称为刘伟楠的账号，却无论如何无法注册。

只要包含刘伟楠三个字，均会被提示“不符合规则”。

导致这个bug，真正原因我不得而知。但我猜测，可能是由于和新浪的某程序员重名了。这名开发用了这个名字，测试功能，然后忘记删除了……

bug是永远存在的，请不要试图永远消灭它。世界top coders联盟主席Boss Fat给出了关于bug的三大定律：

正确的代码，在某些环境中，会编程bug；正确的代码，在某些人眼中，会视为bug；正确的代码，在上完线之后，会引起bug；

基于这三大铁律，精通社会学的Boss Fat给出了宇宙终极定理：

只要某事物被置于某系统中，与其他事物配合驱动系统运行，则此事物无法彻底摆脱bug。

bug的定义，是会随着依赖环境、不同需求、时间推移变化的

bug是常量，没人能永远消灭它。

当然，还有一点

bug养活了多少程序员

而你

却总想着永远消灭它？