对于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养活了多少程序员
而你
却总想着永远消灭它?