程序员每天都在做三件事：写bug、修bug、背锅。连程序员都自嘲，为什么天天加班？因为我的眼睛经常有虫子。那么，您如何编写一个（国王）很难找到的错误？1-新手开发+新手测试=无敌巨坑一天早上，一群程序员被电话轰炸吵醒了。用户纷纷抱怨自己的业务数据莫名其妙地消失了！大家查了半天，原来是新人小王给自己埋的坑。他三个月前开发的定时任务出了bug！当时刚来的小王写完了代码，然后教新来的测试实习生怎么测试代码。估计这姑娘还没想明白。等到里面逻辑混乱的时候，就把代码放到网上。没想到这个bug隐藏了这么久。错误的逻辑导致错误的数据，错误的数据导致任务执行死循环。当执行时间过长时，到了某个时刻，系统像汽水瓶打开一样“砰”的一声。地面塌陷。对业务不熟悉导致逻辑理解出现问题，这是大多数新人都会有的问题。这时候最好安排有经验的测试“调优”，减少bug的发生。2-不管系统的可扩展性如何，如何方便，如何写出史上最著名的“千年虫”bug，引起全世界的恐慌，甚至传出“世界末日”的谣言。理由很可笑：当时的程序员没有考虑到这个软件要到21世纪才能使用，所以为了节省内存，省略了代表年份的前两位，或者说前两位是“19”默认情况下。“千年虫”一千年一遇，但与时间相关的低级bug在日常生活中经常发生，而且通常要等到一段时间后的某个时间点才会暴露出来，让人防不胜防.比如regex只匹配了“16”和“17”这两个年份，直到18年的零点到来才暴露出问题。关于时间的bug很多，从闰年、夏令时、节假日、时区等等，到时间格式，每年都会不小心漏掉时间bug，所以很多公司都有很多时间的通用测试用例。除了时间问题，如果程序员只考虑这个需求或者单一系统，往往会把字段设置错误。当后续业务开发或与其他系统交互时，发现字段不够用，只能修改字段长度。3-无视上下游系统，不打招呼就随意更换接口。曾经遇到过，A系统上线后，大家又恢复了A系统的正常运行，正在松口气的时候，本来运行良好的B系统突然出现故障。B组的人查了半天，发现A提供的接口变了，B系统不兼容新的接口。一个程序员走过的最长的路，大概就是指责之路。2005年12月8日，瑞穗证券一名交易员误输入了错误的股价。两分钟后，交易员试图通过交易软件取消卖单。但连续3次输入撤单指令均被东方证券交易所交易系统拒绝。这次事故造成了400亿日元的损失。后来发现交易系统有bug，是程序员在2000年的一次程序修改中不小心埋下的。因此，很多公司都会严格要求，程序修改后，必须经过严格的回归测试来验证是否对其他业务流程有影响。4-复制粘贴，我闭上眼睛，我看不到任何错误，你调试了吗？发布并验证过的代码安全可靠，可以立即使用。不用质疑，不用浪费时间debug，这就是程序员的惯性思维。被载入史册的漏洞王之一的阿丽亚娜5号的自毁事件就是代码重用造成的。1996年6月4日，阿丽亚娜5号运载火箭发射点火后，由于故障，火箭在发射39秒后偏离轨道，最终被迫引爆自毁。之所以会出现这种情况，是因为五式火箭是在四式火箭的基础上发展起来的，而发射系统的代码程序员也直接照抄了四式火箭。这段代码在四型火箭中已经反复验证，但在五型火箭中没有。事实上，4型的飞行条件与5型完全不同，最终导致事故发生，损失3.7亿美元。有测试工程师表示，最怕开发者说这次没有变化，类似于线上的某个功能。这时候需要仔细验证代码的正确性。这是因为“安全心理”：程序员直觉上相信网上的代码是正确的，所以直接复制使用，而不是花时间自测，因为它是“正确的”和“不容置疑的”。这个时候，测试人员不要轻易听信开发的话，对待他们更应该严谨一些。毕竟，程序员的三大谎言是：没问题；仅更改了两行代码；和网上一样。程序员花30分钟写程序，花2小时修复错误。虫子子孙无穷无尽。所以，面对测试人员的质疑，程序员一定要保持冷静，迅速甩锅：这是历史问题，我没碰过；我刚才还好，但是你的环境不对；重启试试……第一步就是两个字：我改！
