程序员的何写日常三件事：写bug、改bug、让人背锅。何写连程序员都自我调侃道，让人为什么每天都在加班?何写因为我的眼里常含bug。

那么如何写出一个让(坑)人(王)很(之)难(王)发现的让人bug呢?

1 -新手开发+新手测试=无敌巨坑

有一天凌晨，某组的何写程序员们被电话轰炸醒了。用户纷纷投诉自己的让人业务数据离奇消失了!

大伙排查半天，原来是何写新来的小王埋的坑。他三个月前开发的让人定时任务出bug了!

那时刚来的小王刷刷地将代码写完后，手把手教新来的何写测试实习妹子怎样测试这块代码，估计是让人妹子还没搞清楚里面的逻辑时便稀里糊涂地将代码上线了。

万万没想到这bug隐藏这么久，何写由于错误的让人逻辑导致错误的数据，错误的何写数据导致任务死循环执行，当执行的时间过长，到某个点时，亿华云计算系统如汽水开瓶般“砰”地崩了。

业务不熟导致逻辑理解有问题，是大部分新人都会存在的问题。此时***安排个有经验的测试“调教”下，降低bug发生率。

2 -不考虑系统拓展性，怎么方便怎么写

史上最出名的“千年虫”bug令全世界恐慌，甚至传出“世界末日”的谣言。

原因竟让人啼笑皆非：当时的程序员没考虑到软件会被使用至21世纪，为了节省内存省略掉代表年份的前两位数字”19”，或者默认前两位为”19”。

“千年虫“千年一遇，可日常关于时间的低级bug经常发生，而且通常等到一段时间后的某个特定时间点才暴露出来，让人防不胜防。

例如正则只匹配了“16”，“17”年，等到18年零点到来问题才暴露。

关于时间的bug非常多，大到闰年、夏令时、节假日、时区等，高防服务器小到时间格式，每年都会碰到不小心遗漏的时间bug，所以很多公司对时间的通用测试用例就有许多条。

除了时间问题，程序员如果只考虑本次需求或者单个系统时，常常将字段设置不正确，后续业务拓展或者和别的系统交互时发现字段不够用，只能修改字段长度了。

3 -不考虑上下游系统，招呼不打便随意改接口

曾遇到A系统上线后，大伙回归A系统正常运行后，正乐滋滋地松一口气之际，本来好端端运行的B系统突然坏了，B组人排查半天发现，原来是A提供的接口改了，B系统不兼容新接口。

大概程序员走过最长的路便是背锅之路了。

2005 年 12 月 8 日瑞穗证券的交易员因手误输入错的股价，2 分钟后这人试图通过交易软件撤销这笔卖单。可是连续输入 3 次撤单指令，都被东证的交易系统拒绝了。亿华云这次事故造成400 亿日元的损失。

后来查明是交易系统出 bug了，程序员在 2000 年某次程序修改时不小心埋进去的。

所以很多公司会严格要求在程序修改后必须经过严格的回归测试，来验证对其他业务流程有没有影响。 

4 -复制、粘贴，我闭着眼，有bug看不见，debug了没?

已发布已验证的代码，是安全可靠的，是可以拿来即用的，无需质疑，不用浪费时间去调试，这是程序员的惯性思维。

被记入史上bug王之一的阿丽亚娜5型自毁事件就是因代码复用而导致的。1996年6月4日，阿丽亚娜5型运载火箭发射点火后，由于bug，在发射39秒后火箭发生偏轨，最终被迫引爆自毁。

这件事情发生的原因是因为5型火箭是基于4型火箭开发的，发射系统的代码程序员也直接照搬4型的。

该段代码在4型火箭中被反复验证，但在5型却没有进行验证。实际上4型的飞行条件和5型的飞行条件截然不同，最终导致事故发生，此次事故损失3.7亿美元。

有测试工程师说，最害怕开发说这次没啥改动，跟线上某功能差不多。这时候反而要细心验证代码的正确性。

这是因为“安全心理”作祟：程序员直觉已信任上线的代码是正确的，便直接复制过来用，不会再花时间自测，因为这是“对的”，“毋庸置疑”的。

此时测试人员不可轻易听信开发的话，更要严谨对待，毕竟程序员的三大谎言有：没问题的；只改了两行代码；和线上一样。 

程序员花30分钟写程序，花2小时改bug。bug，子子孙孙无穷尽也。所以在面对测试人员的质疑时，程序员们一定要保持镇定，该甩锅时速速甩掉：这是历史问题，我没动过；刚刚在我这是好的，你环境配错了；你重启试试……

***一招是两个字：我改!