这个故事是我最近在LinkedIn上的Multics论坛上发布的消息的编辑版本。
让你的改动很快就"上线",是一种强大的激励。 这是关于我在Multics中引入的第一个bug的故事,Multics是20世纪60年代末70年代初在麻省理工学院创建的一个重要操作系统。
我是一名年轻的麻省理工学院新生,被Multics项目录取。我自告奋勇地在dprint("daemon print")命令中增加了一个功能,将请求排成队列让行式打印机守护进程处理。其中一位经理要求我记录请求中的副本数,而不是将N个请求添加到队列中。这个改动可以解决涉及删除已完成打印请求的竞赛条件。我做了这些改动,并进行了满意的测试。
我的修改很快就安装好了,我很高兴可以改进系统。但我的兴奋是短暂的,因为我很快就接了办公室的电话,发现自己在听一个愤怒的用户抱怨我弄坏了他的程序。我回去一看,我没有注意到,也没有测试过,子程序的入口点进入同一个源文件。果然,我把它弄坏了。我把它修好了,生活继续。但我一直没有忘记那个电话。我仍然不完美,但脑海里回荡着的那个愤怒的声音,让我在此后的岁月里避免了许多类似的、粗心的错误。
我从这个案例中创造出的箴言是"未经测试的代码不能用"。
测试你的代码。找出你自己的bug,不要让别人发现。避免愤怒的声音